Turnkey workstation contract: boundaries of responsibility

What “turnkey workstations” are and where disputes usually occur

“Turnkey workstation” typically means a ready‑to‑use package: a device (PC, all‑in‑one or laptop), operating system, drivers, basic configuration, necessary applications, access and a clear acceptance result. The problem is different parties interpret this term differently. For that reason, a contract for turnkey workstations often becomes a source of disputes not because of the hardware, but because of what exactly counts as “ready”.

Conflicts often start with “it doesn't work”, which hides many causes: an account or permissions were not provided, an app was installed but not activated, drivers or updates are missing, or security settings block launch. Sometimes a license was bought for the wrong product, lacks documentation, or is unsuitable for the intended use. Another common mismatch: the customer expects data migration and peripheral configuration, while the contractor treats those as separate services.

It’s important to fix responsibility boundaries before purchases and deployment. If you buy devices and licenses first and only later determine who is responsible for the OS image, activation keys, compliance with security policies and acceptance documents, fixes become expensive and contentious.

A simple example: a user receives a new PC but Outlook won’t connect. The contractor says “email is not our scope”, the customer replies “the workstation must work”. Such a dispute can be avoided if the contract specifies who configures the profile, who issues access, and who verifies functionality.

This clarification benefits everyone: the customer gets measurable results; the integrator avoids being liable for others’ processes; the security team avoids informal settings; procurement and accounting get licensing and documentation aligned.

How to describe the contract subject in plain language

The contract subject should be phrased so not only a lawyer but also an IT manager, accountant and end user understand it. If the text contains phrases like “installation and configuration” without specifying what and to what result, a dispute is almost guaranteed.

It’s convenient to describe the contract via roles, the delivery contents and a clear “finish”.

First, record the parties and roles. Typically there is a customer, a contractor or integrator, hardware manufacturer and software vendors. Even if the contract is with a single contractor, explicitly indicate who supplies hardware, who performs deployment, and who holds license rights and under what terms they are used.

Next, describe the object of the contract in measurable terms: number of workstations, types, sites, peripherals and special requirements. For example: 120 office PCs, 30 touch all‑in‑ones, 10 engineering workstations, plus printers, scanners, headsets and delivery to three addresses.

To avoid arguing over the word “ready”, define the boundary between “ready to work” and “in operation”. Practical rule: “ready to work” means the user can sign in, open required applications and print a test page. “In operation” begins after acceptance is signed and the documentation package is handed over.

Success criteria are best written as verifiable items: what is included in each workstation (model, components, peripherals), which software and versions are installed and what basic settings are applied, which test scenarios will be used (domain login or local account, network, printing), the schedule and format of acceptance (in batches or all at once), and which acceptance artifacts are delivered (acts, registries, instructions, keys).

The idea is simple: if a workstation “doesn’t work”, the contract should let you quickly determine whether it’s the contractor’s area (for example, a missing printer driver) or the customer’s area (for example, account not created on time).

Responsibility layers: from hardware to end‑user applications

To avoid “gray zones” in a turnkey workstation contract, it helps to break down the deliverable into layers. Then “it doesn’t work” becomes a clear question: at which level did the failure occur and who is responsible.

A practical structure is usually enough:

• Hardware: PCs/monitors/peripherals, warranty, serial numbers, basic testing.
• BIOS/UEFI: versions, passwords, Secure Boot/TPM, boot order.
• OS and base configuration: edition, language, image, accounts, policies.
• Drivers and updates: sources, versions, update window, reboot rules.
• Application software and user environment: list of programs, versions, plugins, profiles, shortcuts.

A key wording note: “install” and “ensure operability” are not the same. Installation can mean “the package was placed”, but not guarantee startup under proxy, DLP or without required domain rights. If you need operability, specify the conditions in which it is tested and who ensures those conditions.

Separately record dependencies that lie outside the workstation delivery: domain/AD, network and VLAN, DNS/NTP, mail, proxy, antivirus/EDR, DLP, printing and print server drivers. Otherwise the contractor “configures” and the customer “doesn’t provide access”, and acceptance stalls.

A practical approach is to separate “device configuration” and “infrastructure readiness”. For example, the contractor configures the user profile and Outlook while the customer provides the account, mailbox and access to auto‑configuration ahead of time.

Before work begins, agree on a short set of rules: which accesses the customer provides and when (AD, networks, proxy, update repositories); what counts as “works” for each program (test scenario); who is responsible for security policies that may block launch; who maintains the image, driver and application version records; and where support responsibility ends after commissioning.

OS, drivers and updates: where to draw the line

The most common OS disputes start with “who should install this and who is responsible if something breaks afterward”. In a turnkey workstation contract, build the boundary between supplying a base configuration and ongoing support in advance.

OS: image, edition and activation

Specify who provides the OS image and who has the right to modify it. If the customer requires a corporate “gold image” with domain settings, state clearly that the contractor will install that image and that responsibility for its contents and compatibility rests with the customer. If the contractor prepares the image, they are responsible for correct installation and repeatability of results.

Also record edition, language, bitness and activation method (KMS, MAK, OEM) and who provides keys. A common practice: the customer provides licenses and activation data, the contractor performs installation and confirms activation in acceptance materials.

Drivers, patches and security settings

Drivers are a risk area because “everything seems to work” until you connect a printer, attach a second monitor or start a video conference. Agree who chooses driver versions and how testing is done.

A useful boundary can be a simple block:

• OS: who supplies the image, who agrees the edition and language, who performs installation.
• Activation: who provides licenses and keys, who ensures successful activation.
• Drivers: who selects versions, who tests them on typical scenarios (printing, network, sound, camera).
• Updates: what is included in the delivery (for example, patches current on the acceptance date) and what belongs to SLA support.
• Security settings: who approves policies (encryption, security agents), who implements them and what counts as “successful implementation”.

Example: the contractor delivered PCs and acceptance passed, but a week later an update caused a scanner to stop working. If the contract states that updates after acceptance are the customer’s responsibility, rollback and compatibility checks are the customer’s task. If updates are included in support, the contractor restores functionality per agreed procedure.

Application software: lists, versions, settings and compatibility

When a turnkey workstation contract includes “install application software”, disputes often arise not over installation but over expectations: which versions, which plugins are mandatory, what “works” means and who is responsible for compatibility.

How to describe the software set

A practical approach is to fix the list not “in general” but by user role (for example: accounting, call center, engineers, managers). Then it’s clear where standard sets (office suite, browser, PDF reader) apply and where specialized apps are needed.

To avoid ambiguity, state who provides installers and distributions (or access to them), who provides keys/accounts/subscriptions, who maintains the version registry and installation dates (what was installed on which PC), and who approves changes (updates, replacements, removals).

Short example: the customer asks to “install CAD”, later it turns out a specific build and plugin for an old project is required. Without a version registry and a clear distributor source a dispute is almost inevitable.

Compatibility and settings

Agree in advance the supported versions and run a short pilot: verify startup, printing, access to network resources, working with digital signatures or certificates if required.

Settings are better fixed as acceptance parameters: document templates, policies, proxy, root certificates, mail parameters, required browser extensions. If the contractor configures these as part of the turnkey scope, the acceptance artifact should include not only a “checkbox” but a clear description of what exactly and where was configured.

Licenses and right of use: how not to create risk for both parties

Licenses are often left “between the lines” in turnkey workstation contracts. Software is installed and people work, but later an audit, staff change or upgrade reveals unclear ownership and responsibility.

Immediately separate two things: who buys licenses and who ensures compliance with their terms. The buyer typically stores proofs (agreements, invoices, keys, vendor emails, portal details), while the contractor is responsible only for installing permitted software and correctly recording what was installed on each device.

To avoid disputes over each program, record a minimum: who purchases licenses and by what deadlines before installation; where supporting documents are stored and who provides them during an audit; license type per product (device, user, subscription) and how quantities are counted; who creates and manages vendor portal accounts and who is responsible for accesses; what happens when a subscription ends, an account is blocked or licensing rules change.

For third‑party software (Microsoft, Oracle, SAP and others) clarify who accepts vendor terms, who handles activation correspondence, who provides portal access and what counts as “license readiness” (for example, an activated key, an assigned user, access to subscription).

The main risk for both sides is “software is installed but there is no license”. Forbid installation without proof of usage rights and add a simple control: reconcile installed software with the approved registry at acceptance. For example, the contractor provides a list of installed applications tied to device serial numbers, and the customer confirms that each item has a license or written permission to replace it with a free alternative.

Step‑by‑step workflow: from preparation to commissioning

To avoid disputes at acceptance, record the sequence of work and the customer’s input data in the contract. Then it’s clear at which step a problem can appear and who fixes it.

Start with planning. A contractor cannot “guess” the customer’s environment, so list required inputs and assign a person responsible for providing them: accounts and roles (local or domain), network parameters (VLAN, DNS, proxy, Wi‑Fi, access to update repositories), security requirements (antivirus, encryption, USB restrictions, logging), the software list with versions and distribution sources, maintenance windows and site access rules.

Next comes the standard. The contractor assembles the “gold image” or installation package: OS, drivers, base settings, required agents and mandatory apps. Define a pilot, for example 3–5 workstations in a typical unit. After the pilot record versions and checksums so mass deployment is repeatable.

Rollout usually surfaces practical items: delivery, unpacking, labeling, connecting monitors and peripherals, joining the domain, installing apps and testing printers. If the integrator supplies equipment (for example, workstations or all‑in‑ones), specify who is responsible for peripheral compatibility and driver availability.

Describe handover as a checklist verification with clear criteria: boot and user sign‑in, network and access to required resources, operation of key applications, printing/scanning (if required), defect remediation and re‑check.

This sequence helps quickly separate “network not configured” from “wrong driver” and prevents turning acceptance into a wording dispute.

Acceptance artifacts: what the customer should receive

After handing over workstations, the acceptance act is not the only important document. If a month later some PCs are in repair, an audit of licenses occurs or a dispute about “it was like this” arises, the set of documents and registries kept by the customer resolves issues.

A minimum artifact package should be specified in the contract or its annex:

• Equipment registry: model, configuration, serial numbers, warranty, commissioning date and physical location of each workstation.
• Software registry: what is installed, versions, source (distribution), who provided licenses and on what basis they are used.
• Acts and reports: acceptance act, test protocols according to agreed checks, a list of defects with deadlines for correction.
• Operational documents: short user guide, administrator guide, deployment diagram (how to recover and update).
• Security materials: which policies were applied, which agents are installed (EDR, DLP etc.), which exceptions were made and who approved them.

Small example: the contractor delivered 200 workstations and two weeks later accounting complains “it doesn’t print”. If there is an equipment registry and test report, you can see which driver and printer model were tested and what constituted a successful test. The dispute quickly becomes a task with a clear owner.

Before acceptance it’s helpful to demonstrate artifacts match reality: spot‑check serial numbers, open the installed software list, verify license proofs and view the signed defect list.

RACI matrix: a simple way to fix responsibility zones

When a turnkey workstation contract lacks clear roles, any error becomes a dispute: “that’s your area” vs “that’s your infrastructure”. A RACI matrix helps fix who performs the work (R), who signs off and is accountable (A), who is consulted (C) and who is informed (I).

For RACI to work, break it down by layers: OS and image, drivers, domain and accounts, network and Wi‑Fi, security (antivirus, policies, encryption), application software, printing and scanning.

Example lines for a single workstation (shortened):

• OS: install and configure — R: contractor, A: customer, C: customer security, I: support team
• Drivers: chipset, video, printing — R: contractor, A: customer, C: manufacturer/vendor, I: users
• Domain and accounts — R: customer, A: customer, C: contractor, I: users
• Application software per list — R: contractor, A: customer, C: app owner, I: security
• Printing on a specific network — R: customer, A: customer, C: contractor, I: users

Then tie RACI to stages: pilot (verify image and app set on real tasks), rollout (mass install and serial tracking), acceptance (checklist and artifacts), warranty (who receives incidents, response times, what is a defect vs a change).

The most valuable part is describing exceptions and gray zones. For example: who is responsible for OS updates after acceptance, how to act when a driver conflicts with corporate security policy, what to do if an app requires unusual privileges or an old component version. Make formulas unambiguous: “the contractor does X if Y holds; if Y is absent, responsibility is with the customer; the contractor consults for Z days”.

If workstations are supplied as ready hardware (PCs, all‑in‑ones or server side for VDI), RACI is especially important at the hardware‑infrastructure boundary. It becomes easier to agree where manufacturer/integrator responsibility ends and customer IT responsibility begins.

A realistic example: how a “non‑working workstation” dispute looks

A typical dispute: the workstation was formally accepted but on the first day the user says nothing works. The contractor replies: “OS is installed, drivers are present, from now on it's your IT”, while the customer insists that a turnkey contract means the contractor handles the problem entirely.

Integration practice scenario: PCs were delivered, printer and token connected, required apps installed. At acceptance everything started, but within a week support requests flowed in.

What usually breaks and where the boundary lies

1. “OS installed but not activated.” Often the contractor installs the OS, but the key, KMS/MAK or access to the activation server is provided by the customer. The contract should state who provides keys and access and within what timeframe. Otherwise workstations will remain idle.

2. “Driver is present but the peripheral doesn’t work.” The contractor is responsible for installing drivers for agreed models, and the customer must list those models in advance (printers, scanners, token devices) and make them available for testing before mass deployment.

3. “Application crashes.” Separate installation (contractor), base configuration (per specification), licensing (who buys and how it’s registered), compatibility (supported OS and dependencies), and security constraints (policies, EDR, whitelists) which the customer may change.

4. “User cannot sign in.” Accounts, permissions, domain, MFA and group memberships are typically the customer’s IT area. The contractor configures the client and domain join but won’t create privileges on the fly unless agreed.

How to record incidents after handover

To avoid arguing verbally, agree on a simple ticket format during warranty: serial and inventory numbers, error text and screenshot, what changed (updates, security policies, peripheral replacements), steps taken and by whom, response time and recovery criterion.

This turns disputes into verifiable diagnostics: what belonged to the contractor at acceptance and what changed on the customer’s side afterwards.

Common contract and specification mistakes that cost dearly

Most expensive conflicts arise not from “bad work” but from vague formulations. Turnkey workstation contracts often contain general terms interpreted differently by each party.

Typical errors that lead to disputes and delays:

• Software listed “in general” (for example, “office suite, browser, antivirus”) without versions, language, bitness and distribution source.
• No definition of “ready to work”: what the user must be able to do and which checks count as successful.
• One document mixes equipment supply, configuration work and ongoing support but does not define when operational responsibility shifts to the customer.
• Customer obligations are not described: who provides accesses, prepares the network and domain, approves maintenance windows, and makes decisions onsite.
• No change management rules: after installing “one more security agent” drivers or domain login may break and everyone looks for the guilty party.

A common scenario: the workstation is accepted and acts signed, a week later the customer security team installs a new agent. After reboot printing and camera stop working. The contractor says “this is an environment change”, the customer says “you delivered the workstation”. Without a change procedure and a cutoff time both sides lose time and money.

To close risks, add basics to the specification and contract: clear acceptance criteria (checks and expected results), software list with versions and installation parameters, responsibility boundary by time (before commissioning and after), change order (who initiates, who approves, who pays, how results are recorded).

Quick checklist before signing and before acceptance

Before signing a turnkey workstation contract, go through a short checklist. It helps separate default configuration from what the contractor must actually deliver and reduces acceptance disputes.

Before signing confirm the contract and spec explicitly state:

• Workstation composition by layers: hardware, OS, drivers, updates, domain/accounts, network, printing, basic security policies and application list.
• Who is responsible for compatibility: for example, if “1С/client of the bank” works only with a specific OS version or requires antivirus exceptions.
• How changes are managed: image versions, policies, exceptions and what counts as scope change and how it is agreed.
• Software licenses: license type, on whom the usage right is registered, what documents are handed over and who stores them.
• Post‑commissioning support: where to send requests, response times, maintenance windows, escalation procedure and what is a warranty case.

Before acceptance ensure you will have evidence and the ability to reproduce the configuration.

At acceptance request and verify:

• Registry of delivered workstations (serial numbers, configuration, location or user mapping if needed).
• Acceptance acts and test protocols: domain login, access to network resources, printing to specific printers, updates, basic security checks.
• List of installed software with versions and key settings, including exceptions and permissions.
• User and admin instructions: how to recover, reinstall, connect peripherals, and where to open support tickets.
• Accesses and passwords: delivered in an acceptable format (for example, sealed envelope or corporate secrets manager) with an indicated owner.

If the contractor also provides support, agree in advance which requests go to the support service and which go back to the deployment team. This saves time on routing tasks between parties.

Next steps: how to prepare and choose the work format

Start with a short set of inputs. The more precisely you describe who and how will work on the computer, the fewer surprises at acceptance. Immediately separate mandatory requirements (without which you cannot run) and desirable items (can be implemented later).

Check that you have ready: user roles and typical scenarios (accounting, operators, medical staff, classrooms), a software list with versions, plugins and languages, security requirements (domain, encryption, antivirus, device restrictions, logs), procurement rules and proof of license legality, and site conditions (network, power, printers, scanners, peripherals).

Then attach three items to the contract: RACI by layers (hardware, OS, drivers, software, updates), acceptance criteria and the list of acceptance artifacts (images, registries, acts, instructions, license records). If these are not attached, a dispute is almost certain.

Before mass rollout run a pilot on 2–5 workstations. Choose “complex” roles, run real tasks and issue a short protocol: what is accepted, what needs refinement, who and in what timeframe will deliver fixes.

Also agree the boundary between project and support: when deployment ends and SLA starts, which channels and service windows are used, who applies updates and how requests are formalized.

If you need both hardware supply and deployment, it is often convenient to pick a vendor who covers the full cycle and then supports the fleet. For example, GSE.kz (gse.kz) manufactures PCs, all‑in‑ones and servers in Kazakhstan and acts as a system integrator, which simplifies dividing responsibility between hardware supply, deployment and ongoing support.