A launched website keeps changing: dependencies, integrations, business rules and content evolve. Even without new pages, a payment API or hosting configuration may change. Support is an agreed process for monitoring, changes and recovery that helps the team respond to problems. It should be clear to both the website owner and the provider.
Separate routine work from incidents
Routine work includes reviewing updates, certificates, logs and backups. An incident means an agreed function is no longer working: the website is unavailable, a form does not send enquiries or a payment does not update an order. A new design or module may belong to separate product development. Distinguishing these avoids turning the incident channel into a stream of feature requests.
An SLA should distinguish response and recovery time
Response means a report has been accepted and handled according to the procedure. Recovery means an agreed function is available again. Diagnosis, an external provider’s response or a temporary workaround may sit between them. Saying we respond quickly does not explain what will happen during an outage.
| Support term |
What to define |
|
Support hours |
When the channel is staffed and what happens outside those hours |
|
Incident severity |
Business impact and prioritisation |
|
Response |
Start of handling and the responsible contact |
|
Recovery |
Agreed outcome, dependencies and confirmation method |
A backup becomes useful when recovery is tested
Know exactly what is backed up: code, uploaded files, the database and necessary configuration. Define storage location, access and retention separately. Copying into the same account that could be lost with the website does not cover every scenario. Demonstrate readiness through recovery in an isolated environment and checks of important functions.
During work on the current ALL IT Agency website, we kept separate local copies and checked file SHA-256 hashes before changes. This verifies the integrity of copied files. Matching hashes do not, however, replace checking that the entire application starts and, where a database is used, that it can be restored.
Learning scenario: the site loads, but enquiries do not arrive
An external homepage check sees a successful response, but the enquiry delivery channel has failed. Availability monitoring may not notice this. Critical functions need dedicated checks and outcome logs. Test enquiries should be clearly labelled and agreed so they do not create unwanted work for the real team.
After fixing the issue, check new submissions and any enquiries saved during the incident. The responsible person needs to know whether data was lost and whether a queue needs manual handling. The impact on the workflow determines when the incident is actually resolved.
How to organise changes with controlled risk
Check updates in an appropriate test environment first. Before changing anything, agree the backup, validation method and rollback conditions. Afterwards, test key routes, forms and integrations. A support report should explain what changed, how the result was confirmed and which dependencies remain. That is more useful than a list of technical actions without their effect on the website.
Sources and further reading
