Technical support for IT systems is contracted recurring work that keeps a company’s website, CRM, ERP and services running: monitoring, handling requests within agreed timeframes, updates, backups and a report on what was done. Support for business systems starts at $700 per month, website support at $250 per month.
Key takeaways
Support differs from calling a specialist after a breakdown in that the scope is described in advance and part of it is carried out before anything breaks. A visiting administrator shows up once there is an outage; support works to a routine.
Development sits apart: new features, integrations and reports are not support but work on estimate or a separate package with a fixed number of hours. A website with its own set of tasks — domain, certificate, page monitoring — is covered in the article on website support after launch.
Support begins not with monitoring but with an inventory: which systems exist, which servers they run on, who uses them and what happens to the business if each one stops. Without that map any agreement about response times hangs in the air — nobody can say what counts as critical.
Criticality is defined by the consequences for the business, not by opinions about which system feels more important.
Monitoring grows out of that map: scenario checks and alerts to the engineer on duty for critical systems, basic availability and resource checks for the rest. Automated monitoring does not depend on the time of day, but the response time of people is a matter for the contract.
An SLA is a service level agreement, in other words the contractor’s written obligations: which channels requests arrive through, how priority is determined, how quickly the team starts work and what happens if a deadline is missed. Unlike verbal promises, it gives the client a formal instrument rather than a reason to be upset.
| Priority | Example request | What the contract fixes |
|---|---|---|
| Critical | The CRM is down, payments fail, data is lost | Work starts immediately, plus escalation order and a way to reach the team outside working hours |
| High | A feature is broken but there is a workaround | Response time during working hours and an indicative resolution time |
| Normal | An employee’s question, a small edit, a report setting | The queue and a planned deadline, plus the monthly volume of minor work |
| Change | A new feature, an integration, a new report | A separate estimate: timing and cost agreed before work starts |
Important There are no universal numbers in an SLA: the actual response hours depend on the set of systems, the company’s working hours and the cost of downtime. In our support contract the response time depends on the plan: eight business hours for a critical failure on weekday cover, four hours with Saturday cover until 22:00, and one hour on round-the-clock cover.
The report exists so that the monthly fee does not look like a payment for silence. It shows what you are paying for and what changed in the infrastructure during the month.
A separate line is the review of recurring failures. In engineering practice this is called a blameless incident review: the Google SRE book describes it as a written record of an incident, its impact, the actions taken to resolve it, the root causes and the follow-up actions that prevent recurrence. The point is to change systems and processes rather than to name a culprit.
The choice depends not on the size of the company but on how many systems it runs, how expensive downtime is and whether there is someone inside to set tasks for an external team. Outsourcing means handing part of the work to a contractor under a contract; it does not remove the need for someone internally who understands what the company wants from IT.
| Criterion | In-house administrator | Outsourcing | Mixed model |
|---|---|---|---|
| Knowledge of your specifics | Highest: the person is inside the processes | Built during handover and recorded in documentation | The internal employee supplies context, the contractor covers the technology |
| Holidays, sick leave, resignation | Work stops or falls on other people | The obligations stay with the contracting company | Cover from both sides |
| Range of skills | Limited by one person’s experience | Wider thanks to the contractor’s different specialists | Narrow tasks go outside, daily ones stay in |
| Costs | Salary, taxes, workplace, training | A fixed amount under the contract | Salary and the monthly fee at once, but the load is shared |
| Accountability | An employment contract | A contract with agreed response times | Split by areas, described in advance |
| Who it suits | Plenty of on-site hardware and constant in-office tasks | Key systems run remotely and predictable response is needed | The company has grown but has no IT department yet |
An honest comparison is not “salary versus monthly fee” but total cost: taxes and equipment, training, the manager’s time spent assigning tasks and the price of the downtime that never happened.
Handover is a separate stage before the monthly service starts. It exists so that the contractor is accountable for something it actually understands rather than signing blind for somebody else’s legacy.
The honest conclusion of a handover sounds like this: this part can be supported as it is, and that part is cheaper to rebuild than to repair every month. A plan for a serious outage is the subject of a separate article on recovering IT systems after incidents.
An external team gets access to systems that hold customer and employee data, so the access rules are written down before the work starts. In Uzbekistan this is not only a matter of trust: the Law on Personal Data (No. ZRU-547 of 02.07.2019) requires legal, organisational and technical protection measures from the owner, the operator and any third party alike, and the confidentiality requirement covers everyone who has been given access to the data.
How this works inside systems that hold a customer database — roles, restrictions and the event log — is covered in the article on access rights in a CRM.
The key sign of a mature contractor is that it offers to define the boundaries of the work before the contract is signed instead of promising to solve everything. Run through the list before agreeing.
The price depends on what is taken under watch and how expensive downtime of those systems is. The technical support page lists three packages with different scopes.
Syntra Systems takes on projects built by others: we study the code, the infrastructure and the settings, record the risks and only then agree to support them. Recurring failures are traced to the root — otherwise support turns into putting out the same fires. We keep documentation and hand it over together with the access credentials, so that a change of team does not leave you with a black box.
The server side can be covered along with support when needed: a server for a website or a CRM in a data centre in Uzbekistan starts at $30 per month, and the scope of the work is described on the servers and cloud page.
Let’s discuss your project
Tell us what you need, and we will estimate the timeline and cost and suggest a solution.
Yes, the two fit together. The in-house specialist handles daily tasks and knows the company’s specifics, while the external team takes monitoring, complex incidents and areas that need narrow expertise. The areas of responsibility are described in advance, otherwise tasks start falling between the two sides.
Monitoring runs around the clock, but how fast a person responds depends on the plan in the contract: a critical failure gets an eight-business-hour response on a weekday plan, four hours on a plan running until 22:00 including Saturdays, and one hour on a round-the-clock plan.
It is safer than a shared administrator password known to half the office — provided the accounts are personal, the rights are minimal and access is revoked when the work ends. The confidentiality requirement covers everyone who has been given access to personal data, and the contractor’s accountability is set out in the contract and the NDA.
We do, but first we run a handover: we go through the code, the servers and the settings, collect all the access credentials and record the risks. Based on that, we honestly split the system into what can stay and what's cheaper to rebuild. Taking responsibility for someone else's solution without that check wouldn't be fair to you.
Support keeps the system running: monitoring, incidents, updates, backups and minor edits within an agreed volume. Development changes what the system can do — new features, integrations, reports — and is either estimated separately or delivered in a development package with a fixed number of hours per month.
Access to every system registered in the company’s name, infrastructure documentation, backups and the source code with its change history. Write this into the contract from the start: then changing teams stays a routine task instead of a reason to rebuild the project from scratch.
From the monthly report: how many requests there were, which updates were installed, whether restore tests passed and which risks were closed. The absence of outages is the result of that work rather than a coincidence, and the report shows which actions produced it.
