Support teams run on routines: collecting diagnostics for a ticket, restarting a stuck service, rotating a certificate, confirming that a nightly job finished. Every routine can be performed in three broad ways, and picking the wrong one for the stage a team is at is a common source of both wasted hours and avoidable incidents. This comparison sets out the three approaches, where each fits, and a precise rule for moving a routine from one to the next.
The three approaches
Approach A: fully manual
An engineer performs the routine from experience or from rough notes. Each step is typed or clicked, and the engineer interprets everything along the way.
Strengths: flexible, cheap to start, ideal while the routine is still being understood. Weaknesses: slow, inconsistent between people, and dependent on memory, especially under pressure.
Approach B: semi-automated
The fixed steps are templated or scripted, but a person starts the routine, reviews key outputs and makes the decisions. A typical example is a script that gathers logs, system state and recent changes into a bundle, which an engineer then reads.
Strengths: consistent, quick, still guided by human judgment. Weaknesses: needs upkeep, and tends to become a pile of loosely documented scripts if nobody owns it.
Approach C: fully scripted
The routine runs end to end without a person, triggered by a schedule or an event, with notification on failure.
Strengths: no waiting, no fatigue, no variation. Weaknesses: a wrong assumption is repeated at machine speed, and subtle changes in the environment may cause quiet failure.
A comparison on six criteria
- Speed: manual is slowest, semi-automated is fast for the fixed part, scripted is fastest.
- Consistency: manual varies by person, semi-automated is consistent in the scripted part only, scripted is uniform.
- Risk of silent error: manual errors are visible to the person doing the work, scripted errors may go unnoticed until someone checks.
- Setup cost: manual is nil, semi-automated is moderate, scripted is highest.
- Upkeep: manual needs training, the other two need review as systems change.
- Suitability for judgment: manual is best, semi-automated adequate, scripted poor.
No approach wins on every line. That is the point: the question is not which is best but which fits the routine in its current state.
The rule for moving between approaches
A routine should move from A to B only after it has been performed manually at least three times, by more than one person if possible, with each run recorded. The records must show a set of steps that are identical in every run. Those identical steps become the scripted part.
A routine should move from B to C only when three further conditions hold. The semi-automated version has run for a meaningful period without producing a wrong result. Every decision the person used to make has been either removed on evidence or replaced by an explicit, testable rule. And failure produces a clear alert to a named owner.
Where those conditions are not met, remain at B. Many routines should stay there permanently, and that is not a failure.
Which routines belong where
- Stay at A: rare, novel or high-stakes events, such as the first appearance of an unfamiliar fault.
- Move to B: diagnostic collection, standard checks after a deploy, drafting the usual customer updates.
- Move to C: routine housekeeping with well-understood failure modes, such as log cleanup within clear limits or a nightly job verification.
For more on the thinking that underlies this kind of choice, consider the discussion in an article about the principles behind effective software delivery, which supports the idea of reducing repetitive manual effort without removing accountability.
Cost comparison, qualitatively
Teams often compare only setup cost. A fairer view adds the cost of repeated manual execution, the cost of errors and the cost of keeping an automation current. A routine run once a month rarely justifies full scripting. One run several times a day almost always does. In between, B is typically the economical choice. Estimate with your own numbers, not with someone else’s benchmark.
The move toward infrastructure defined in code and shared operations practice, discussed in an article asking how operations staff gain from adopting DevOps, from infrastructure as code up to SRE, is one reason scripted routines are now so much easier to build and maintain.
One routine through all three stages
Take a certificate expiry check. At stage A, an engineer opens each host and reads the date, noting which ones are close. At stage B, a script lists every certificate with its remaining days, and the engineer decides which to renew first. At stage C, the script renews certificates inside a safe window on its own and alerts a named owner whenever a renewal fails. Each stage is correct for a particular level of understanding, and the earlier two are what make the third trustworthy.
An outside comparison
Intake in other sectors shows the same graduation. HipHospitals is a medical tourism website with hospital and doctor listings sorted by country, plus forms that overseas visitors can use to ask for a quote or an appointment. Think of the forms as the B stage of an enquiry process: the first contact is structured, while a human handles what follows. The example concerns administration alone and makes no clinical claim.
Governance of each approach
- For A, keep running notes that can feed the future script.
- For B, give each script an owner, a short description of its assumptions and a review date.
- For C, require alerting, a documented stop switch and a periodic audit that the output is still correct.
A decision table in words
If the routine is new or varies a lot, choose A. If it is stable but needs interpretation, choose B. If it is stable, well understood, low in consequence and produces output that can be checked automatically, consider C. If you are uncertain, choose the earlier stage, since stepping forward later is cheap and stepping back after an incident is not.
Conclusion
Manual, semi-automated and scripted routines are stages, not rivals. Perform by hand until the identical steps are evident, script those steps, and let a person keep every decision that requires context. Advance to full automation only when evidence and alerting justify it. Support teams that follow this sequence deliver steadier service with less strain on the people providing it.
