Who owns support after an application goes live?

Before you go live, give four support jobs a named owner. A business owner sets priorities and approves workarounds and changes. A first point of contact takes user questions. A technical lead or supplier fixes faults and maintains the system. Someone looks after backups, renewals and suppliers. In a small business, one person may hold several of these jobs. Write each one down, with support hours, the route for urgent issues and what the fee covers, whether that is an annual maintenance contract (AMC) or a monthly arrangement. Then test it with a real request before launch, not on the first busy Monday.

Separate the questions users will bring

“The application is not working” can mean a failed sign-in, an incorrect record, an unavailable service or an unfamiliar task. A new feature request may arrive through the same channel.

These issues need different responses. Agree where users should report them and who will make the initial assessment. A single visible route can work even when several people or suppliers provide the answer behind it.

Assign the business decisions too

A technical provider can investigate a fault. Someone in the business still needs to decide its operational impact, approve a workaround and confirm whether normal work has resumed.

In a small team, one person may cover several responsibilities. That can be workable if their authority, availability and backup arrangements are understood.

What exactly should support promise you?

Establish the hours during which the service is monitored and the route for urgent incidents. An inbox that nobody monitors outside working hours is not an out-of-hours support arrangement.

Distinguish acknowledgement, investigation, restoration and final resolution. A promise to respond within an agreed period does not necessarily promise that every issue will be fixed within that period. Define severity using the effect on business activity and agree how updates will be communicated.

Also clarify which work is included in the support fee. A defect, a configuration request, a training question and a new integration may fall under different commercial arrangements.

Buying support as an annual maintenance contract (AMC)? Read its scope against the table above. An AMC that covers “maintenance” can still leave out user questions, new reports or fixes needed when a connected service updates. Ask the supplier to list what is included, not what is excluded.

Prepare for more than the original developer being available

The handover should identify the relevant accounts, administrative contacts, technical documentation and known limitations. Access should be provided through authorised accounts and appropriate credential management; passwords should not be placed in a general handover document.

For a purchased cloud application, establish what the supplier manages and what remains with your business. For a custom application, record the responsibilities across application code, hosting, dependencies and integrations. Backup and recovery duties should be explicit for the information and services within scope.

How long does the build team stay on after launch?

Many software agreements give a period after launch when the developer fixes defects at no extra charge. It may be called a warranty or stabilisation period. Find out when it ends, what counts as a defect rather than a change, and what takes over next.

If another provider or an AMC will take over, finish that handover before the period ends. Not after the first incident.

Rehearse a support request

Before launch, walk through an ordinary user question and a service interruption. Check who receives each report, who can act and who informs the affected staff. Record any dependency on a person who has not agreed to provide support.

Two of our worked examples show this handover in practice: replacing a shared spreadsheet with an application and helping a team adopt a new application.

The Government Digital Service’s published support guidance provides a useful operational reference: it distinguishes support levels and calls for documented support routes and operating hours. The appropriate arrangement for a business should reflect its own application and staffing.

Further reading: How GDS provides user support.

Common questions

In a small business, who should users contact first when they need help?

One route that everyone actually uses. It can be a named person, a shared inbox someone checks, or a request form. Your own staff or the supplier can sit behind it. Either way, a named person in the business still decides priorities and approves workarounds.

Is a quick response the same as a quick fix?

No. A response time promises that someone acknowledges the issue or starts looking into it. Getting you working again, and fixing the cause, are separate promises. Your agreement should say which ones it makes.

What should a software annual maintenance contract (AMC) cover?

The work it covers, named one by one: defect fixes, updates, renewals, backups, user help and small changes. Plus the support hours and the route for urgent issues. Anything not named, such as new features or integrations, is usually charged separately. Ask before you sign, not when the first invoice arrives.

Planning a launch or taking over an application?

Tell us which application is launching or changing hands, and who supports it now. We can start with the rehearsal described above. Ongoing support is a monthly fee.

Send an enquiry →

Related capability:Technology & Automation →