Why is a separate contract needed at all?
Some businesses think, "If something breaks, I'll call a specialist and pay for the work." This approach is valid for a home computer. For a business system, it's a risk.
Without a support contract: at a critical moment, there may not be an available specialist, each request is paid "at market rates" — often significantly higher than the subscription price, there are no guarantees on response time — the system may be down for days, it is not updated to comply with legislation — reporting risks not being accepted.
The contract shifts support from "we'll buy when needed" to a predictable process with fixed costs and guarantees.
Section 1: Subject of the Agreement and Scope of Services
It clearly specifies WHAT is being provided. There should be a list: technical user consultations, system bug fixes, updates for changes in legislation, configuration of new reports, training of new employees, adjustments for changes in processes.
Avoid formulations like "provision of technical support services." It means nothing. There should be a clear and specific list.
Chapter 2: What is NOT included (important!)
It is separately specified what is NOT included in the subscription fee — to avoid disputes. Usually, this includes: development of new modules, hardware upgrades, training large groups of new employees, integration with external systems, data recovery after user errors.
This does not mean that it won't be done — just for an additional fee. It's better to arrange this in advance than to argue later.
Chapter 3: Communication Channels and Response Time (SLA)
How and when can you request support: hotline phone number, email for written inquiries, ticket system, messengers (WhatsApp).
Response time (Service Level Agreement) is a key point of the contract. It should be: for critical incidents (the system is down, the accounting department cannot submit reports) — 1-2 hours, for important incidents (a specific function is not working) — up to 4-8 hours, for regular consultations — 1-2 business days.
Without an SLA, the response time can be "whenever we can" — and you depend on the contractor's mood.
Section 4: Support Working Hours
Common options: working hours (8/5) — Mon-Fri 9:00 AM - 6:00 PM, extended (16/7) — 7 days a week from 6 AM to 10 PM, 24/7 — around the clock, no days off.
For most businesses, the optimal schedule is 8/5 — it addresses most issues, reporting, and weekends. A 16/7 schedule is only necessary for critical production systems or retail.
SPOC, for example, provides support 16/7 — this covers the needs of 95% of our clients.
Chapter 5: Hours and Billing
Typically, the subscription fee includes a certain number of hours per month. Any additional hours are charged extra. It should be specified: the number of hours in the package (for example, 5/20/40 per month), the cost of an hour beyond the package, and whether unused hours can be carried over to the next month.
The alternative is "payment upon fact": you pay only for the work that has actually been completed. This is suitable for businesses with a small volume of requests and for those that do not critically need timely updates.
Chapter 6: Reporting and Transparency
A good contractor provides a report every month: what requests were made, how much time was spent, what work was completed, and what is planned for the next period.
The contract must specify: the report format, the frequency of provision, and the possibility of operational control (ticket system where you can see the status of requests).
Chapter 7: Liability of the Parties
What will happen if the contractor fails to fulfill their obligations. Standard options: a discount for the next month in case of SLA violations, the possibility of early termination of the contract in case of systematic violations.
Avoid contracts where the responsibility is only outlined on your side (payment terms, penalties for late payment). It should be mutual.
Chapter 8: Access and Security
The contractor gaining access to your systems is a sensitive issue. The contract should include: NDA (non-disclosure agreement), data access rules (who, when, for what purpose), logging of the contractor's actions, and the return/destruction of access upon termination of the contract.
For businesses with personal customer data (medicine, banks, e-commerce), this is especially critical.
Chapter 9: Terms of Contract Termination
How exactly can the collaboration be terminated? There should be: a notice period for termination (usually 30-60 days), a procedure for transferring data and access, which occurs with unfinished work.
Avoid contracts with strict "tie-ins" — for example, for 3 years without the possibility of termination. This is a sign of bad practice.
Bonus points to add
Regular system audit. Once every six months to a year, the contractor conducts a review — how the system is functioning, whether there are any issues, and what can be optimized.
Development recommendations. Not just "putting out fires," but also proactively suggesting improvements.
Guarantee of knowledge of your system. Attachment to a specific specialist or team that understands the specifics of your business.
Discounts on revisions. Within the support contract — preferential rates for new work.
Are you looking for a partner for technical support of the accounting system?
SPOC provides technical support 16/7 with a clear SLA and transparent reporting. Leave a request — we will prepare a contract tailored to your business.