The website is live, the team has shared the link and the project has reached an important milestone. Then ordinary business continues. A contact address changes. A service is withdrawn. A dependency needs an update. A form stops delivering messages. Someone needs to notice and act.
This is why post-launch support should be discussed before the final invoice. “Maintenance included” sounds reassuring, but it can mean very different things to different people. A useful agreement makes the responsibility concrete.
What does the support agreement cover?
Content changes, technical upkeep, incident response and new features are different activities. Updating a team biography is not the same job as diagnosing a failed payment flow. A new customer portal should not quietly become an expectation inside an arrangement intended for routine upkeep.
Ask what is included, how requests are submitted, when they are reviewed and what would require a separate estimate. Clear boundaries protect the working relationship and help the business plan improvements rather than discovering the distinction during an urgent request.
A page can open while a form is broken.
A service can be reachable while a key journey is broken. Alongside availability, think about the actions that matter: sending an enquiry, signing in, completing a booking or receiving an expected notification. Decide which checks can be automated and which need occasional human review.
Give each alert an owner and an escalation route. A warning sent to an inbox nobody checks is weak protection. Agree what information should accompany a problem report, while avoiding unnecessary customer data in screenshots or logs. The goal is to help the right person understand the issue quickly.
Backups and updates need an owner.
The NCSC’s backup guidance explains the importance of protecting useful information and being able to recover it. For a website or application, the support arrangement should identify what is backed up, how long copies are retained and how restoration is checked.
Updates also need an owner. The NCSC’s device-protection guidance reinforces keeping software current. The exact update process for a business platform depends on its technology and risk. Ask how changes are reviewed, tested and recovered if they introduce a problem rather than assuming every update is either harmless or something to postpone forever.
Make room for ordinary improvements.
Set aside a regular opportunity to look at customer questions, incomplete journeys, content accuracy and operational friction. The frequency should suit the business and how often the platform changes. A quiet brochure site and a busy operational application do not need identical support plans.
Keep the support contact, request process and escalation route somewhere the team can find them. Agree who can authorise chargeable work and what happens outside normal support hours. When a problem occurs, staff should be able to act from that agreement rather than search through old messages to work out who is responsible.
Read further
Original sources behind the technical guidance in this article.