24/7 Support Contract for a Mixed IT Environment

Why confusion quickly appears in a mixed environment

In a mixed IT environment, a problem almost never stays within a single layer. A user works on their PC, an application talks to a server, the server talks to a database, and data moves through integration components. If a failure starts in one place, it is often noticed somewhere else.

This is the main source of confusion. Contractors usually are responsible only for their own area: one handles servers, another — workstations, a third — OS, a fourth — DBMS, a fifth — integrations. Formally the zones are clear. In practice an incident passes through several levels at once, and that's when the argument begins about who should accept the ticket, who must check adjacent components, and who is responsible for bringing the work to a result.

A good example is when an accountant sees that the program has "frozen" on their PC. It may look like a workstation issue. But the PC itself can be fine; the error may have started on the application server, then reached the database and only then became visible to the user. If the contract doesn't clarify who takes such an incident into work and who coordinates the investigation, the ticket starts circulating.

This is especially costly at night, on weekends and holidays. By day a dispute about boundaries can be resolved quickly by a call or a message. In 24/7 mode every extra handoff adds minutes and hours of downtime. That becomes a risk to office operations, checkout systems, accounting systems and exchanges with branches.

Confusion most often arises at four points:

• no single point of incident intake;
• each team sees only its own fragment;
• no one is obliged to check adjacent components;
• tickets are closed by layer responsibility rather than by actual service restoration.

Therefore a 24/7 support contract for a mixed infrastructure cannot be assembled as a set of separate services. If the project includes servers, workstations, OS, DBMS and integrations, the document should view the service as a whole. This is especially important for large organizations where hardware, system components and support are distributed among different teams. Even if the infrastructure is built on locally produced servers and workstations, disputed zones do not disappear by themselves. They are removed only by clear boundaries, unified escalation rules and a clear incident owner.

What to include in the support perimeter

The support perimeter should be described so there is no room for guesswork. A general phrase like "IT infrastructure support" is almost useless. In the contract it is better to list explicitly what is covered by the service.

Start by fixing the main nodes: servers, workstations, virtual machines, domain controllers, storage systems, terminal servers, mail services and other critical points. For each object it's useful to indicate a name, role, location and the unit that depends on it.

Specify software versions separately. If the document doesn't list editions and versions of OS, DBMS and application systems, it's easy later to get a dispute like: "we don't support this version." This is especially important in environments where some systems run on Windows, others on Linux, databases have been updated unevenly, and an application depends on specific libraries and drivers.

Many forget about integration components, though problems there occur as often as on servers. If the business depends on exchanges between systems, the support perimeter should include at least:

• messaging services and queues;
• APIs, connectors and gateways;
• scheduled file exchanges;
• integrations with mail, user directories and external services;
• scheduled tasks, scripts and background procedures.

Another important block is environments. You must state explicitly whether only production is supported or if test, staging and disaster-recovery environments are included as well. Without this, a contractor may formally refuse to investigate an issue on a test bench even if it was found there before going to production.

It's also important to list exclusions. Typically the contract does not include development of new functionality, changes to business logic, purchasing licenses, equipment replacement outside an agreed procedure, user training and support for third-party services that are not on the approved list. The more precise this section is, the fewer disputed calls at night.

A simple rule of thumb: any object, version or exchange without which a business process stops should be named explicitly. Everything else is either included by a separate clause or remains outside the perimeter.

How to divide zones of responsibility

If this is not done in advance, any serious failure quickly turns into a dispute. The server is reachable, but the database doesn't respond. The database is running, but the exchange doesn't work. The workstation powers on, but the user can't log in. In such a project it's better to break boundaries down by layers: hardware, OS, DBMS, applications and integrations.

The main rule is simple: each layer must have one primary responsible party. Not two and not "depending on the situation." Otherwise teams will spend the night exchanging messages instead of restoring service.

Where the boundary runs

Hardware is typically responsible for servers, workstations, disks, memory, network cards and basic hardware failure diagnostics. The OS is responsible for booting, user accounts, services, updates and error logs. The DBMS is responsible for instance availability, backups, recovery and basic operational parameters. Applications and integrations are responsible for business logic, queues, connectors, APIs and correct data exchange.

You should also explicitly state where the contractor's zone ends and the customer's begins. On the customer's side usually remain access credentials, change approvals, confirmation of maintenance windows, an up-to-date contact list and notification of external changes with their vendors. Without this even a strong support provider can't act quickly. For example, a contractor sees an access-rights error in the database but does not have the right to change accounts without approval. Formally the delay is no longer on their side.

Decide in advance who communicates with vendors and external contractors. If you use solutions from Microsoft, Oracle, SAP or other vendors, the contract should specify who opens cases, who collects logs, who handles correspondence and who makes the final decision on fixes.

It's convenient to summarize roles in a simple table:

If part of the infrastructure is supplied and supported by a single integrator, it's better to reflect that separately. That reduces gray zones between "hardware" and the basic system part, and escalation is faster. For companies in Kazakhstan this approach is often convenient when one partner covers both hardware and integration. For example, GSE.kz combines the role of hardware manufacturer and system integrator, so responsibility boundaries in such projects are easier to fix within a single scope.

How to assemble the contract step by step

A good support contract is rarely written from scratch. First collect the facts: what runs in the company, who uses it, which services cannot be stopped and who is responsible for each layer. Otherwise even a strong contractor will spend time determining the responsibility zone.

In a mixed environment it's useful to start from the composition of the infrastructure, not from elegant phrases. First break the project into layers: hardware, workstations, OS, databases, integrations, backups, communication channels. After that, build the document step by step.

1. Compose a systems map. You need a single list of servers, workstations, virtual machines, OS, DBMS, mail, business applications and exchanges. Next to each, indicate the owner on the customer side and the executor.
2. Separate critical from secondary. Not all services are equally important at night. A calculation database and payment integration may require immediate reaction, while updating a driver on an office PC can wait until morning.
3. Describe typical failures by layer. For servers it's disk failure or overheating; for workstations — login problems, network or printing issues; for OS — freezes and update errors; for DBMS — service stops, locks, lack of space; for integrations — stopped exchanges or corrupted queues.
4. Fix the communication order. The document should specify clear channels for emergency and routine requests, responsible persons, backup contacts and escalation levels.
5. Put measurable rules in appendices. Keep the main contract compact, and put SLA, priority matrix, list of supported systems and maintenance windows in separate appendices. They are easier to update without rewriting the whole text.

A simple scenario shows the value of such preparation. At night an exchange between the accounting system and the database stops. If the contract already defines the server owner, the DBMS responsible, the escalation order and reaction times for critical services, the team does not argue but immediately starts work.

Which SLA conditions should be specified

The main mistake in SLA for a mixed environment is to set one universal time "for all cases." For servers, workstations, OS, DBMS and integrations this almost always leads to disputes. The executor believes they responded on time, while the customer expects full service restoration. So separate response time and recovery time from the start.

Response time shows when the ticket was taken into work and actions began. Recovery time shows when the service works again in the agreed scope. For critical systems these are two different metrics and both should be fixed in the contract.

Different timelines for different incident types

Identical norms for any problem are inconvenient for both the business and the provider. It's better to split requests into at least a few categories:

• outage — the service is completely unavailable, work stopped;
• degradation — the service runs but is slow, error-prone or partial;
• request — configuration, consultation, user account, planned change;
• integration issue — data is not transmitted between systems or is transmitted incorrectly.

Each category needs its own response and recovery times. A DBMS outage at night and a request to install a printer in the morning cannot be handled under the same norm.

If support is claimed as round-the-clock, specify night hours, weekends and holidays separately. The important thing is not the promise of "24/7" itself, but the details: who answers the call, who has access to systems, who approves emergency actions and what work can be performed without additional approval.

Planned maintenance windows are also better fixed in advance. This protects both parties. The customer understands when short interruptions are possible, and the provider is not held liable for an agreed OS, DBMS or integration module update.

Finally, there should be a clear rule for pausing SLA. Time is usually stopped if the customer did not grant access to the system, there is no approving employee, the problem is caused by an external communications or power provider, or a spare part or license must be awaited under agreed conditions. The more precisely this is defined, the easier it is later to evaluate support quality without double interpretations.

Practical example: office, servers, database and exchanges

On Monday at 9:10 some employees boot their workstations but cannot log in. For some the authentication window freezes, for others the application opens but shows no data. For the manager the picture is simple: work has stopped and the cause is unknown.

At first glance the server looks guilty. But the server may be reachable and show no hardware errors. The source of the failure is often on the client device side, the user profile, network settings or the workstation OS.

There is also the reverse situation. Login works, but documents are not posted, data is not pulled, and the exchange with another system has stopped. Then you need to look into the DBMS, the integration service or the exchange queue.

That is why the contract should not be limited to the phrase "support of the entire IT infrastructure." If the project has servers, workstations, OS, a database and exchanges, a clear diagnostic route from the first call is necessary.

The typical workflow looks like this:

• first-line support accepts the request and records exactly who can't use the system;
• they quickly check the scope: one user, a department or the whole company;
• simultaneously they check the client side, the application server, the DBMS and integration services;
• after localization the incident is handed to the appropriate team, but without losing overall control.

Here it's important not only to have ordered steps but also a single responsible party. If one contractor manages workstations, a second — servers, a third — the database, and a fourth — exchanges, the customer will quickly be left between them. Each will prove the problem is not theirs.

Therefore the contract should immediately include a rule: one executor is responsible for overall coordination of the incident until full service restoration. Even if they involve other teams, they collect logs, correlate error times, keep contact with the customer and drive the incident to closure.

Common wording mistakes

The most frequent mistake is to write that the contractor "supports the entire IT infrastructure" and not to clarify what that means. For a mixed environment this is a dangerous formulation. Each party easily interprets servers, workstations, OS, DBMS, backups, integrations, network equipment and application services in their own way.

Another problem is an SLA without conditions, exclusions and pauses. If the document only says "response 15 minutes, resolution 4 hours" but doesn't state that times stop when access, approvals or responses from the customer are missing, such an SLA is almost impossible to honor fairly.

A weak point is silence about third-party licenses and external contractors. If the project uses products from major vendors, you need to define in advance who opens vendor cases, who pays for support and who handles incident communication.

Order of access is often forgotten too. For 24/7 support a general promise that "access will be provided" is not enough. The contract should explicitly state:

• which systems are accessible remotely and which only on-site;
• who issues access and in what timeframe;
• whether work outside business hours can be done without separate approval;
• how emergency access to critical nodes is formalized;
• who confirms completion of work.

Another gap is weak reporting requirements. If it's not described what counts as a closed incident, the provider may simply state that functionality is restored. That is insufficient for the customer if the cause, actions taken, downtime and risk of recurrence are unclear.

Therefore for critical incidents immediately fix a minimum set: a work report, a list of actions performed, start and end times, participants from both provider and customer, and the rule that closure occurs only after confirmation of the result.

A short checklist before signing

Before signing it's useful to run through a short list and remove all unclear points. Such a contract should answer not only "what we support" but also "who and how acts at night, on weekends and when systems intersect."

Check five things:

• all systems are named explicitly, not vague terms like "server part";
• critical services have assigned priorities and clear response and recovery times;
• contacts, roles and escalation paths are specified, including first line and emergency approvals;
• backups are described separately: who makes copies, who checks their success and who is responsible for test restores;
• the change procedure and planned maintenance plan are in place so a night update does not become a separate dispute.

If the project is mixed, ask for an appendix to the contract in the form of a simple table: object, owner, support hours, priority, SLA and comments. This format is easier to read for IT teams, lawyers and managers.

For large organizations where servers, workstations and integration components are provided by different companies, this step is especially important. It helps agree the real support boundaries in advance and eliminate disputes before the service goes live.

What to do next

If you are preparing a 24/7 support contract, don't start with a template. First gather a complete picture of what exactly needs support. In practice conflicts usually arise not because of price, but because some systems were simply omitted from the perimeter.

Consolidate a single registry of all support objects: servers, workstations, OS, DBMS, backups, integrations, network nodes and critical services. For each item immediately indicate the owner, installation location, level of importance and dependencies on other components.

After that decide where you want a single executor and where multiple providers are acceptable. If the infrastructure is tightly coupled, a single point of responsibility usually reduces the number of disputes. If some systems are already supported by vendors or an internal team, that's also workable, but roles must be separated very clearly.

A practical course of action is:

• compile a unified registry of hardware, software and integrations;
• mark critical nodes whose downtime immediately affects the business;
• determine who is responsible for first line, diagnosis, fix and escalation;
• request a draft contract together with appendices for SLA, procedures and roles.

It's especially important to ask not only for the main text but for appendices. They usually fix response times, recovery times, service hours, contact channels, exclusions, maintenance windows and responsibility boundaries. If these appendices are missing, the contract will look neat only on paper.

It's useful to test the draft with a simple scenario: the database is unavailable, users cannot log into the system, and the cause is unknown. Who accepts the ticket at night? Who checks the server? Who checks the OS? Who connects to the DBMS? Who is responsible if the problem is in the exchange between systems? If these questions can't be answered in a minute, the document is still raw.

For companies in Kazakhstan it's often convenient to have a partner who can cover not only support but the infrastructure itself. For example, GSE.kz manufactures computers, servers, workstations and all-in-ones in Kazakhstan and also works as a system integrator. In mixed-environment projects this helps reduce gaps between hardware supply, basic system setup and ongoing support.

A good next step is simple: compile the registry, send it to a potential contractor and ask them to return a contract draft already filled with roles, SLA and exclusions. Then the discussion won't revolve around general promises but on a concrete support model.