Choose software support by defining the response, restoration and decision ownership your business needs when the application stops working properly. A supplier can acknowledge a ticket quickly while the customer-facing problem remains unresolved. UK and Irish buyers should understand what each support commitment measures before comparing retainers or response-time promises.
This guide focuses on post-launch service operations for custom applications. It works for local suppliers and remote engineering teams. It does not treat the UK and Ireland as a single legal jurisdiction: contractual and data obligations need the appropriate separate review. The practical procurement task is to make the operating responsibilities visible enough to price and manage.
Define support around business impact
List the activities that depend on the software. A booking service, internal reporting tool and order-processing application may need different coverage. Identify when each activity is used and what staff can do if it becomes unavailable.
Then write severity examples. An outage affecting all customers, an incorrect financial calculation and a cosmetic defect should not automatically enter the same queue. Equally, a problem affecting one user may be urgent if that person is responsible for a time-sensitive business operation.
Agree who can assign and change severity. Require a short explanation tied to impact, affected users and available workarounds. This prevents an incident discussion from becoming an argument about labels while the actual problem continues.
Separate the support clocks
Ask the proposal to distinguish acknowledgement, investigation, restoration and permanent resolution. State when measurement starts, which hours count and what events pause a commitment. Check whether an automated email qualifies as the promised response or whether a qualified person must engage.
- ▸Acknowledgement: The report is received and ownership is established.
- ▸Investigation: A qualified responder begins assessing the issue.
- ▸Restoration: The agreed business activity can resume, possibly through a documented workaround.
- ▸Resolution: The underlying defect is corrected and the change is verified.
These are definitions to negotiate, not universal service levels. A buyer should not impose a restoration promise that neither party can realistically support. Where the outcome depends on another provider, ask what the supplier can commit to doing and how progress will be communicated.
An incident that tests the wording
Imagine a membership organisation whose portal accepts payment but fails to send confirmations. This is an illustrative scenario, not a customer result. The site is online, so a simple uptime check remains green. Staff begin receiving messages from applicants who are unsure whether to pay again.
An adequate support scope explains how the team recognizes the affected journey, establishes which payments succeeded and prevents avoidable repeat attempts. It also identifies who can approve a temporary customer message and who decides whether new applications should be paused.
Restoring email delivery may not finish the incident. Someone still needs to reconcile the affected applications and send missing confirmations. Ask whether that operational repair is included, requires buyer participation or becomes separately chargeable work. All three arrangements are possible; uncertainty is the avoidable problem.
Assign technical and communication ownership
Name the person or role coordinating a significant incident, the team making technical changes and the person updating business stakeholders. Small teams may combine roles, but the responsibilities should remain explicit. Google's SRE incident-management chapter explains why clear roles and coordinated communication matter during service disruption.
The buyer should know where to obtain the latest state without repeatedly interrupting an engineer. Agree an update cadence and an escalation route when the impact increases. An update can honestly state that the cause is still under investigation while describing observed impact and the next decision.
Record significant actions, approvals and changes in a shared incident history. This is especially valuable when a remote team changes shifts. Responsibility should transfer explicitly rather than disappearing between the end of one person's day and the start of another's.
Identify third-party dependencies
Map the suppliers behind the service: hosting, identity, payment, messaging and other critical integrations. Confirm who holds the support entitlement for each and whether your software partner can open and manage a case on your behalf.
The UK NCSC supply-chain security guidance provides broader supplier-management context. For your support contract, make the result practical: a named owner, valid contact, accessible account and agreed coordination task for each dependency.
Ask what happens when the software partner believes a third party caused the issue. Does it remain the coordinating contact, or is the ticket closed? Can it collect the evidence the other provider needs? An exclusion for third-party faults should not accidentally leave the buyer without anyone managing the incident.
Match coverage to the operating calendar
State support hours in the buyer's business time zone and specify the applicable working calendar. Clarify weekends, bank holidays, seasonal peaks and out-of-hours escalation. Do not assume that English-language communication means an overseas team shares the buyer's calendar.
If you need extended cover for a launch or critical period, price it explicitly. Ask who is available, how they are contacted and what system access they already have. A promise to “try the developer” is different from a staffed commitment.
Also identify buyer availability. A supplier may need an authorized decision maker to approve pausing transactions or sending customer communications. The support model should not depend on a buyer contact who is never reachable during the promised service window.
Separate maintenance from new features
Clarify whether the agreement includes dependency updates, security fixes, monitoring changes, incident investigation and recurring operational repair. Describe how work is estimated, approved and reported. Avoid a single undifferentiated allowance that makes it impossible to see where the budget went.
Review recurring incidents and convert appropriate findings into engineering work. The purpose is to reduce repeated disruption, not simply process the same ticket faster every month. Our year-two software cost guide helps place maintenance alongside the original build budget.
Request a support proposal with real scenarios
Give shortlisted suppliers your critical journeys, operating hours, dependencies and example incidents. Use the European software vendor scorecard to compare responsibilities and evidence. Ask each supplier to show what its commitment means for the same failed-payment-confirmation scenario.
TuniCyberLabs provides custom software engineering and scoped ongoing development. Request a software support scope with your application, current operating arrangements and required coverage. The proposal should confirm the support available and identify any needs requiring a different arrangement.