Service Request

A service request is a demand for something the organization has already decided to offer: an environment, a dataset, a permission, a credential, a license. It is one of the standard records in IT service management, and its defining property is that fulfilling it is expected work rather than a repair.

Requests and incidents can arrive through a common channel, but need distinct classification and routing. A request seeks an offered service or action; an incident reports an interruption or degradation. A request is expected demand, not by itself evidence that fulfillment was successful or that the platform meets its commitments.

Count requests separately from incidents while retaining enough detail to interpret both. Incident records need a period, affected population, duration, and duplicate-report handling before they describe reliability. Repeated request records can be receipts from automation or tasks awaiting people. Measure manual intervention, hands-on effort, waiting, failures, and rework. Total intake can help plan staffing, but a combined ticket count alone describes neither service reliability nor fulfillment quality.

The part of the queue that should not exist

Reliability practice has a precise name for repetitive fulfillment work. Toil is “the kind of work tied to running a production service that tends to be manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows.” Each adjective is doing work, and two of them decide most cases.

Judgment is a clue, not an exemption. A new decision about a genuine tradeoff can be engineering work. Google’s footnote also describes recurring alerts that require complex judgment because of avoidable design problems; handling them remains toil until the need is removed. Separate new decisions from recurring diagnosis, and assess redesign as well as automation. Identical approvals suggest a policy check only when the rule, authority, risk, and implementation cost have been established.

Linear scaling. Work that grows with the service turns success into a staffing problem, which is what makes this structural rather than annoying. Hence the stated ceiling: an “advertised goal of keeping operational work (i.e., toil) below 50% of each SRE’s time,” with the rest going to “engineering project work that will either reduce future toil or add service features.” The specific number is less important than having one, because a budget for interrupt work is what makes the question of removing it urgent.

The definition also excludes things people like to call toil, and the exclusion is useful. Administrative chores “should not be categorized as toil: this is overhead,” being work “not directly tied to running a production service.” Team meetings and goal-setting are overhead. Complaining about them as toil hides the distinction that would otherwise tell you what to automate.

Reading the queue by cluster

Group requests by the work sought over a stated period. Inspect their arrival rate, age, manual effort, and outcomes. Queue length and cluster shape suggest where to investigate; neither alone identifies the cause or the appropriate investment.

The second row is where good intentions do damage. Automating a question that has not been settled produces many fast, inconsistent answers, and the inconsistency is harder to find afterward than the original queue was.

Choosing how to reduce repeated handling

The progression is laid out in the reliability workbook and it is worth following to the end, because stopping early feels like finishing. A remediation document is already most of the way to code: steps of the form “log in to X, execute this command, check the output, restart Y if you see” some symptom “are essentially pseudocode to someone with software development skills.”

The workbook describes moving from a procedure to a script, automating detection and remediation, or changing the software so the failure no longer occurs. These options remove different amounts of work and introduce different maintenance and control requirements. A manually launched script can be an appropriate intermediate improvement. Measure the human effort that remains and compare further automation or redesign against its cost and risk.

One thing to keep while climbing: the record. The reason a request queue exists is not only fulfillment — it is knowing who asked, what they got, and who approved it. A self-service path that provisions silently has removed the toil and the audit trail together, which is a trade nobody agreed to. Emit the record from the automation.

An ITSM request offering should state what can be requested, by whom, with which inputs and approvals, who fulfills it, and what outcome and timing the requester may expect. For example, a database offering can specify eligible teams, permitted sizes, cost approval, the provisioning owner, and a way to inspect status or request help. These are illustrative fields, not a universal schema. A service catalog may expose that offering; distinguish this request-and-fulfillment meaning from a software ownership inventory. The Change That Was Approved After It Shipped connects requests with incidents, problems, and changes.

References

• Google, Site Reliability Engineering, Eliminating Toil
• Google, The Site Reliability Workbook, Eliminating Toil