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

v5 · 2026-09-19 · History

Domain-specific #

1410

Domain group

Applied Sciences & Engineering

Origin domain

Computer Science & Software Engineering

Subdomains

It Service Management, Reactive Support Delivery → Computer Science & Software Engineering

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.

How would you explain it like I'm…

Call When It Breaks

Break/Fix is like calling a plumber only when a pipe leaks. Nobody watches your pipes the rest of the time. When something breaks, you call, they fix it, and you pay for that one fix.

Pay-Per-Repair Tech Help

Break/fix is a way of getting help with computers and technology. When something stops working, the customer calls a repair company, which figures out the problem and fixes it, and the customer pays for that particular repair, like the work, the parts, or the service call. Between problems, nobody is paid to keep an eye on things or prevent trouble. That's different from 'managed services,' where a company is paid regularly to watch over and take care of your technology all the time.

Reactive Per-Incident IT Support

Break/Fix is an IT support arrangement in which service starts only after a fault or problem shows up. The customer contacts a provider, who diagnoses and restores the broken equipment or software, and payment is tied to that specific job: the labor, parts, ticket or agreed repair. Two features define it: the work is reactive, triggered by a problem, and what the customer buys is a single intervention rather than ongoing care. A provider can still promise response times or guarantee its repair and be Break/Fix, as long as each job is triggered by a fault and paid for separately. The usual contrast is managed services, where the provider takes continuing responsibility, monitors the systems, meets service levels and is paid on a recurring basis. Under Break/Fix, the customer carries more of the burden of noticing problems and planning for aging equipment, which can be sensible for low-importance or rarely failing systems.

 

Break/fix is an IT support arrangement in which the customer engages a provider after a technology fault, malfunction, or service issue appears, and the provider diagnoses and restores the affected hardware or software under an incident-specific engagement. It rests on two joint commitments: demand is reactive (the fault triggers service), and the commercial unit is the discrete intervention (labor, parts, ticket, or agreed repair) rather than an ongoing bundle of monitoring, prevention, optimization, and lifecycle management. Response targets, repair warranties, or a framework contract do not change the classification as long as the substantive work is fault-triggered and separately consumed. The standard contrast is with managed services, which wrap continuing responsibility, monitoring, defined service levels, and recurring payment around an agreed estate or outcome. Under break/fix, more of the detection, escalation, and lifecycle risk stays with the customer. The contrast is diagnostic rather than a value judgment: break/fix can be rational for low-criticality, infrequently failing, legacy, or transitional assets, whereas managed service fits where downtime costs and prevention justify recurring spend.

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

Current abstraction Break/Fix Domain-specific

Parents (1) — outgoing typed relations

• Break/Fix is a kind of Contract Prime

  Contract is the broader abstraction this entry instantiates.

Hierarchy path (1) — routes to 1 parentless root

• Break/Fix → is a kind of Contract → presupposes, conditional Interface → is a decomposition of Boundary

Neighborhood in Abstraction Space

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

Family — Software & Systems Architecture (32 abstractions)

Nearest neighbors

• P-cycle protection — 0.78
• Patch management — 0.78
• Segment Protection — 0.77
• Data Reporting — 0.77
• Service management — 0.76

Computed from structural-signature embeddings · 2026-10-25