The website has launched, the final invoice has been paid and the project team has moved on. A few months later, something stops working. The business contacts the designer, the designer points to the host and the host asks for more information.
This situation is easier to handle when responsibilities were agreed before the problem occurred. A website usually depends on several people and services. Assuming that somebody else is looking after it creates gaps, even when each supplier is doing the work originally requested.
Businesses can organise ongoing care internally or use a provider such as BugShield for WordPress maintenance. Either way, the useful question is the same: who owns each task, and what happens when a problem crosses more than one supplier’s remit?
Separate the roles before comparing services
Start by listing the different roles involved. The host provides the environment in which the website runs. The designer or developer created the site. Content editors keep information current. Other suppliers may support payments, bookings or email.
The actual responsibilities depend on the agreements you have with them. A host may include some website support, and a developer may offer ongoing care, but neither arrangement should be assumed from the job title alone.
Ask each supplier to describe its scope in writing. A short list of included tasks and exclusions is more useful than relying on what everyone remembers from a conversation during the build.
Give the business an internal owner
Even when technical work is outsourced, someone in the business needs to coordinate decisions. That person does not have to be a developer. They need to understand what the website is for and know where to direct a request.
Choose a deputy so that holidays or absence do not leave urgent issues waiting. Keep contact details, account ownership and the current supplier list accessible to both people.
The internal owner can also distinguish a fault from a request for new work. Asking for a new booking feature is different from reporting that an existing booking button has stopped working.
Put ordinary tasks on a responsibility list
Create a simple list covering software changes, recovery arrangements, monitoring, content updates and customer-journey tests. Assign a named owner to each item and agree when it should be reviewed.
Include business details such as opening hours, contact information and seasonal offers. A technically functional website can still confuse visitors if its information is out of date. These tasks often belong with the business rather than its developer.
Review the list with the people involved. A task is not assigned successfully until the person or supplier expected to do it understands and accepts that responsibility.
Establish how faults are reported
Agree one normal route for reporting issues, with an alternative for an urgent outage. Describe the information that should accompany a report: the page, what happened, when it started and how to reproduce it.
Avoid relying on a vague message such as “the website is broken”. A report explaining that the enquiry confirmation appears but no message arrives gives the investigator a clearer starting point.
Decide who communicates with other suppliers when needed. The business should not have to discover during an incident that every provider expects somebody else to coordinate the investigation.
Explain the boundary between care and development
Routine maintenance does not necessarily include every change a business might want. Discuss how the support agreement treats redesigns, integrations, additional pages and repairs to existing features.
Ask for a clear approval process for chargeable work. The provider should know who can authorise it, and the business should know what information it will receive before deciding. This is particularly useful when several staff members request website changes.
Keep a separate list of improvements that can wait. Mixing those requests with urgent faults makes it harder for everyone to understand priorities.
Keep records useful to the next person
A record of significant changes helps the next developer understand the site. Include what changed, why it changed and which customer functions were checked afterwards. Link to relevant support conversations where practical.
Also record unresolved limitations. If a workaround is in place while a permanent repair is arranged, make that visible. Otherwise, another person may treat the workaround as an intentional part of the design.
Review access when staff or suppliers change. The business needs continuity without depending on a former contractor being available to answer every account question.
Revisit responsibilities as the business grows
A quiet brochure website may become a shop, add bookings or support a paid campaign. Those changes affect how important availability and prompt support become. The original care arrangement may need to change with them.
Set aside time to review what the website now does, what has caused problems and what support has actually been used. Make adjustments based on that experience rather than simply renewing the same arrangement automatically.
Clear responsibility does not remove every technical problem. It makes problems easier to report, investigate and resolve because the business knows who is doing what after launch day is over.