Skip to content

Break/Fix

An IT support arrangement in which a customer requests restoration after a fault or failure and pays the provider for the resulting incident-specific labor, parts, or service rather than for continuous management.

Version
v3 · 2026-09-07 · History
Domain-specific #
1410
Origin domain
IT service management
Subdomain
reactive support delivery
Aliases
Break-fix, Break fix, Break'n fix, Break/fix model, On-demand IT support

Core Idea

Break/fix is an IT support arrangement in which a customer engages a provider after a technology fault, malfunction, or service issue becomes apparent, and the provider diagnoses and restores the affected equipment or software under an incident-specific commercial engagement. Payment is tied to the work, parts, ticket, or agreed repair service rather than to continuous responsibility for managing the environment.

Two commitments define the model together. First, demand is reactive: the fault or customer-reported issue triggers service. Second, the commercial unit is the discrete intervention: the customer purchases the response rather than an ongoing bundle of monitoring, prevention, optimization, and lifecycle management.

Scope of Application

The node covers third-party hardware support, desktop and printer repair, server and storage support, network fault resolution, software troubleshooting, patch or workaround delivery for reported defects, and on-call services for small organizations without a continuing managed-service agreement.

It also covers formal framework contracts under which a customer can call off break/fix work for a listed estate. UK public procurement documents use the term for multi-year hardware-support agreements covering servers, storage, networks, desktops, laptops, and printers. This shows that “break/fix” does not always mean there is no prior contract; the reactive work and incident-bounded obligation distinguish the model.

Clarity

A service qualifies when it can answer:

  1. Which assets or software are eligible?
  2. What fault, report, or call-off activates work?
  3. Who detects and reports the problem?
  4. What diagnosis and restoration actions are in scope?
  5. How are labor, parts, tickets, or outcomes charged or consumed?
  6. When does the provider's responsibility begin and end?
  7. Which preventive monitoring or lifecycle duties are absent or separately contracted?

Manages Complexity

The abstraction compresses timing, responsibility, and payment into one service architecture. It tells buyers, providers, and analysts that issue detection remains largely customer-side, the intervention starts after a fault, and costs are attached to discrete corrective work.

For procurement, the concept exposes scope questions: which devices, locations, parts, hours, response targets, exclusions, and escalation routes are covered? For operations, it predicts a queue initiated by reported incidents rather than by continuous telemetry.

Abstract Reasoning

The signature supports conditional predictions. If failures are rare, assets are noncritical, and internal staff can detect and triage issues, event-driven purchase may cost less than continuous external management. If downtime is expensive, failures interact, or the customer cannot detect degradation early, delayed activation can make apparent savings illusory.

Knowledge Transfer

Within IT, the identity transfers from desktops to servers, storage, networks, printers, applications, and cloud components so long as the fault-triggered, incident-bounded support relation remains. It also transfers to outsourced legacy-equipment support after original manufacturers end coverage.

The nearest cross-domain analogue is out-of-warranty appliance or vehicle repair paid per occurrence. That is a useful analogy but not automatically an instance of this node, whose established vocabulary and procurement practice are IT-specific.

Relationships to Other Abstractions

Local relationship map for Break/FixParents appear above the current abstraction, mutual partners to the right, and children below. Node labels state whether each abstraction is prime or domain-specific; colors identify relation types.Break/FixDOMAINPrime abstraction: Contract — is a kind ofContractPRIME

Current abstraction Break/Fix Domain-specific

Parents (1) — more general patterns this builds on

  • Break/Fix is a kind of Contract Prime

    Contract is the minimal prospective parent.

Hierarchy path (1) — routes to 1 parentless root

Neighborhood in Abstraction Space

Break/Fix sits in a sparse region of the domain-specific corpus (96th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Unclustered & Miscellaneous (1565 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-09-08