After handover: why support and an SLA matter

The project was delivered, the warranty period ended, and the team moved on to another engagement.

Three months later something breaks. You write in - the reply arrives two days later. You write again: "we're busy right now, we'll look next week."

That is not an accusation. If no response time is written into a contract, the team has no basis for prioritising your request over anything else.

How warranty differs from support

These two are frequently conflated, and that is exactly where disputes start.

A warranty says "we stand behind the work we did". It covers technical defects and it is time-limited.

Support says "we are responsible for your system continuing to work". That is a different service: monitoring, backups, a fast response, small changes.

Support begins where the warranty ends. Without an agreement you move into a "whenever we can" arrangement.

What response time actually means

This is the headline figure in an SLA, and it needs to be read correctly.

Response time is the interval from a request arriving to a reply. It is not the time to resolve the problem.

Resolution time depends on complexity and is either agreed separately or not at all.

Workable tiers:

The choice is commercial rather than technical: what does a day without the system cost you? If the number is large, Enterprise is justified. If it is small, Basic is enough.

What belongs inside an SLA

Every tier should include these, and they belong in the contract:

• Response time in hours, specifying working days or 24/7
• Monthly hours allowance - how many are included
• Monitoring - is system health watched and are outages alerted
• Backups - how often and where they are stored
• Recovery time - how long restoration takes after a failure
• What is excluded - new modules, major changes, hardware

The fifth is often missing and it matters more than the rest. Backups exist, but restoring from them takes two days - in practice that is the same as having none.

The three-year total

This calculation belongs at proposal stage, not afterwards.

An example:

Support cost more than the build. That is not a bad thing - the system ran and was maintained for three years. But the figure should be known in advance.

Comparing two proposals: one at $28,000 with $800 a month, another at $38,000 with $300 a month. Over three years the first is $56,800 and the second is $48,800. The cheaper-looking proposal turned out more expensive.

An alternative model: annual percentage

In some cases a percentage of project value replaces the monthly tier.

The usual rate is 18% a year. For a $70,000 system that is $12,600 a year, or $1,050 a month.

When it works better: on larger, more complex systems, particularly with many modules. A monthly tier is more precise for smaller systems.

Both models work - what matters is knowing which one applies and what it includes.

In-house team or external support

This question arrives as a company grows.

In practice a mixed arrangement often works best: an internal person handles day-to-day questions and training, while the external team takes technical work and development.

Clauses your contract needs

• Response time and how it is measured - which channel starts the clock
• Monthly hours and whether unused hours carry forward
• What is included and what is not - a specific list
• Monitoring and backup arrangements
• How and when the price may change
• Termination terms and how data is handed over

The last is forgotten most often. If you decide to change teams, how data, code and documentation transfer should be written down in advance.

When support is not needed

For the sake of honesty this deserves saying.

If the system is simple, no changes are expected, and downtime has no serious effect on the business, a standing SLA is not essential. An hourly arrangement will cost less.

When that fits: a small internal tool, few users, a non-critical process.

When it does not: inventory, point of sale, production, payroll. When those stop, work stops.

In summary

Support is not an extra cost. It is what you pay for the system to keep running, and it belongs in the calculation alongside the project price.

Practical steps:

1. Separate warranty and support clearly in the proposal
2. Choose a response time by business impact rather than by price
3. Calculate the three-year total: project plus 36 months of support
4. Ask about recovery time, not just whether backups exist
5. Sign the agreement before the warranty expires
6. Write termination and data handover into the contract