Can you automate it before you hire for it?

Turn the request into work

Ask the requesting manager to name the duties, the person doing them now and the consequence of leaving them undone. Use a period that includes ordinary demand and the awkward cases. Record planned growth separately from work already arriving.

Start with the capacity inputs guide. It separates total hours from timing and skill constraints. Keep its boundary consistent: if projects are excluded from available support time, exclude project demand too. Missing time records remain a gap, not evidence that nobody worked.

A fictional request for another service coordinator might contain ticket routing, chasing incomplete notes, preparing reports and providing afternoon absence cover. Reducing report preparation would not necessarily give the desk afternoon cover. The current report writer might be a different person, or the released time might occur before the afternoon shift starts.

Write the constraint in service terms: which promise is at risk, when, and which capability is missing. That sentence will become the test for any improvement and the remaining hire.

Remove work that should not continue

Look for duplicate reports, unused checks and repeated approval steps whose original purpose has disappeared. Ask the recipient what decision the output supports. A report no one uses is a removal candidate; a record needed for an agreed service obligation is not disposable just because preparing it is tedious.

Removal needs an owner. Record who agrees to stop the activity, what obligation was checked and how you will notice an adverse effect. Do not delete records or turn off monitoring as a housekeeping experiment.

Also investigate avoidable demand. A recurring workaround may justify fixing the underlying fault rather than teaching a workflow to repeat it. Keep that correction separate from automation credit. If both initiatives claim the same minutes, your capacity calculation will overstate the result.

Standardize before handing anything off

A workflow cannot repair an unresolved disagreement about what counts as urgent, complete or approved. Define the input, required evidence, outcome and exception route. Have two people apply the definition to the same small set of records. Discuss differences before writing code or prompts.

For a ticket-routing candidate, specify which fields determine the suggested queue and what happens when those fields are blank. The safe outcome for incomplete information might be a triage task, not a guessed assignment. A reminder to finish notes needs an agreed note standard first.

Adam Hannemann's AI-fundamentals article argues that an owner needs enough business understanding to notice what an AI answer leaves out.^[1] Apply that discipline here: somebody who understands the work must define the result and challenge the proposed shortcut. A tool's demonstration is not a process definition.

Automate a bounded part

Use the first-candidate guide to compare volume, input quality, reversibility and error cost. Prefer a narrow, observable task with a usable fallback. Report preparation, missing-field reminders and draft summaries are reasonable candidates to inspect, not promises of savings.

Conduit's workflow directory includes triage, reporting and billing reconciliation examples.^[2] Use such recipes to identify a work boundary. Check permissions and source fields in your own systems; a vendor example does not prove that the same workflow is safe or useful for your clients.

For AI-assisted work, retain review of substantive output. NIST identifies confidently false generated content as a risk.^[3] A polished summary still needs a reader who can compare it with the record. Do not give a pilot authority to send replies, modify client systems or approve transactions simply to remove the review time from the calculation.

Put an end date on the test

Choose a scope, named reviewer and decision date before building. A fictional test could cover one internal reporting workflow for two working weeks, with manual preparation available throughout. Those numbers are example boundaries, not a recommended minimum sample or a reliability claim.

Agree what would stop it: wrong-client content, missing source records, unauthorized access, a missed commitment or an exception the reviewer cannot resolve. Identify who can pause the workflow and where outstanding work goes after a pause. A stop control that nobody has tried is an assumption.

Observe manual effort before the change. During the test, count distinct eligible completions, routine review, extra rework and recurring maintenance. Include failed runs. Record setup and training separately. The automation savings guide gives a non-overlapping calculation and preserves zero or negative results.

Keep a comparison group or matched manual cases where feasible. If the test only includes unusually easy work, say so. A process change, missing records or seasonal demand can make before-and-after totals incomparable.

Inspect what the result does not cover

For illustration, a fictional workflow might release six recurring hours in a week and require nine setup hours. That leaves minus three hours in its first week before any other one-time effort. Even a later positive result belongs to a role and time window. It is not automatically six hours of usable on-call coverage.

Keep these duties explicit:

Judgment: resolving conflicting evidence, choosing urgency and accepting risk.
Coverage: being available when the service promise requires a person.
Relationships: understanding a client's priorities and handling a difficult conversation.
On-call responsibility: receiving an escalation and owning the response, including when the workflow fails.

Automation may assist those duties. It has not demonstrated that they can be left unstaffed. Review the residual work with the people accountable for delivery. Do not delay an urgent coverage remedy while waiting for a speculative pilot.

Hire for the remaining constraint

Use the Capacity Decision Lab sample to keep current workload, proposed improvements and first-period effort distinct. Existing automation is already reflected in today's workload and gets no new credit against it.

The decision can be to hire, change the role, standardize further, extend a narrowly justified test or stop it. Record why. A negative pilot result is useful evidence against a proposed workflow, not a reason to conceal maintenance hours.

Saved effort and payroll savings are different claims. Pay, recruitment, cash timing and employment decisions need the responsible owner's separate review. A successful test can improve a job description while leaving the hiring need intact.

The working discipline

Automate before you hire

Remove unnecessary work and agree its standard before testing one bounded workflow. Measure review, rework and maintenance, then hire for the judgment, coverage and relationships that remain; a positive effort result is not proof of payroll savings.

Review the sequence →

Worksheet / Usable takeaway

Hiring-request decision note

Request and accountable manager: [role / duties / decision owner].
Service constraint: [promise at risk / skill / time window / consequence].
Evidence boundary: [team / period / included demand / exclusions / gaps].
Remove: [activity stopped or retained / authority / obligation checked].
Standardize: [input / outcome / exception route / disagreement resolved].
Automate test: [one workflow / eligible unit / scope / start and end dates].
Safeguards: [reviewer / permissions / pause owner / fallback / stop conditions].
Effort result: [manual baseline / review / rework / maintenance / setup / net hours including zero or negative].
Usable capacity: [beneficiary role / time window / overlap with other improvements].
Work that remains human: [judgment / coverage / relationships / on-call duties].
Decision: [hire / revise role / further test / stop / evidence still needed].
Follow-through: [action / receiving owner / due date / result to check].

Open the worksheet: Automate-before-hire decision note Download (Markdown)