Choosing the first workflow to automate

Collect candidates from actual work

Ask the desk and account team which activity they repeat, then inspect the records behind the answer. Describe a work unit: one incomplete ticket flagged, one renewal record checked, or one summary reviewed. "Automate onboarding" is too broad to test as a first workflow.

Count how often the work occurs in a defined period. Distinguish eligible units from retries, monitoring polls and duplicate records. Observe active effort as well as elapsed time. A report that runs slowly but needs little human attention may release less effort than expected.

Record the person who benefits. If you are investigating a hiring request, use the automate-before-hire decision note to connect the candidate with a specific constraint. Automating an owner's report does not by itself repair engineer coverage.

Conduit's advanced-workflow directory contains examples involving ticket triage, licence auditing and renewal reporting.^[2] Treat that as a source of candidate boundaries. Your records establish frequency and effort; the directory does not establish savings for your MSP.

Fix the definition before scoring

Choose the simplest version that would produce a useful outcome. A missing-field reminder can flag an incomplete record without inventing the missing value. A renewal report can collect dates without sending a negotiation email. Those are different permissions and failure costs from changing the underlying records.

Agree what qualifies, what success looks like and which records must stay out. Have the person who does the work and the reviewer classify the same sample manually. If they disagree about whether a ticket is incomplete, fix the entry standard before building the reminder.

Keep missing inputs visible. A workflow that excludes records with blank dates can make the renewal calendar look reassuring while hiding the records most in need of attention. Route unknowns to an owner. Do not substitute a default date just to satisfy a required field.

Use a small score, then inspect it

The following rubric is an editorial comparison aid, not a validated predictor of return. Score each factor from 0 to 2. Two is the more favorable condition for a first pilot. Use unknown instead of a number when you lack evidence, and do not total an incomplete row.

• Volume: 0 means rare or unmeasured, 1 means recurring but modest, 2 means frequent distinct eligible work.
• Rule clarity: 0 means unresolved judgment, 1 means a defined rule with exceptions, 2 means an agreed rule that reviewers apply consistently.
• Input quality: 0 means missing or untrusted inputs, 1 means known gaps with a routing rule, 2 means checked inputs with stable references.
• Error cost: 0 means a mistake could cause material harm, 1 means a contained error still needs prompt correction, 2 means an internal advisory output with limited consequence.
• Reversibility: 0 means difficult or untested recovery, 1 means a documented but untested fallback, 2 means a tested pause and manual fallback with no production write.
• Review capacity: 0 means no receiving reviewer, 1 means a reviewer with uncertain availability, 2 means a named reviewer with time reserved.

There is no universal volume threshold here. Define it against your own workload before scoring. Record the evidence beside the number rather than letting the total become an argument by itself.

A fictional shortlist

All volumes, scores and outcomes in this table are fictional. The monthly units are distinct eligible records, not API calls. Each candidate has already passed an initial scope check; it has not been approved for production.

The note reminder wins this fictional comparison because its outcome is narrow and somebody will review it. Its input-quality score still needs work: the team must agree which fields and exemptions matter.

The last row should not proceed as written. An inferred departure is not an authorized access-removal request. A high score elsewhere would not cancel that problem. Remove unsafe candidates from consideration; never compensate for a serious authorization gap with extra volume points.

For the summary candidate, uncertainty belongs in the result. NIST's generative-AI profile describes false content presented confidently and human over-reliance as risks.^[3] A reviewer needs the original record, not only the generated version. Review availability can therefore decide whether that workflow is worth testing now.

Design the first run to reveal failure

Use fictional or approved, minimized test data first. Include blank inputs, duplicates, changed owners, records outside scope and a dependency that fails. For an advisory report, verify both a normal finding and an unknown result. Confirm that the intended reviewer receives the output and understands its status.

Keep the first version read-only against operational systems where feasible. Give it only the access its defined work requires. Record where data goes, where the output is stored and how long test evidence is retained. The AI safe-use guide provides a separate approval check when an AI tool handles the content.

Set limits on the pilot's scope and duration. Name the pause owner and manual fallback. Prevent duplicate notifications with a stable work-unit reference, and make a failed run visible. A quiet report can mean there were no findings or that the workflow never ran; the reviewer must be able to tell which.

Count the work that remains

Track routine checking, corrections, exceptions and maintenance. A reminder may create useful work rather than remove it. Keep that outcome separate from hours saved. If more complete notes improve handoffs but require more effort, record both facts.

Use the automation savings method after the pilot. Existing automation receives no new credit against current workload. Setup is charged once, and negative recurring savings stay negative.

Choose the next step from observed results: continue within scope, repair the standard, revise the candidate or stop. Any expansion into sending messages or making changes requires another permission and error-cost review. Approval for a report is not approval for an action agent.

The working discipline

Automate before you hire

Standardize the input and success rule before choosing an observable, reversible workflow with a named reviewer. Automate the repeatable check first; people still veto unsafe candidates and decide whether the pilot result warrants expansion.

Review the sequence →

Worksheet / Usable takeaway

Candidate selection and pilot sheet

• Candidate and beneficiary: [one activity / role / constraint it may change].
• Work unit and period: [eligibility rule / distinct count / exclusions].
• Baseline: [observed active minutes / estimate label / source references].
• Standard: [required inputs / success evidence / exception route / reviewer agreement].
• Scores and basis: [volume / rules / inputs / error cost / reversibility / review capacity / unknowns].
• Safety vetoes: [authority gap / data exposure / harm / fallback not tested].
• Selected scope: [read-only or approved writes / data permitted / systems / output destination].
• Test cases: [normal / blank / duplicate / wrong scope / dependency failure].
• Ownership: [builder / reviewer / pause owner / manual fallback owner].
• Pilot boundary: [start / end / maximum eligible work / stop conditions].
• Result: [outcome quality / remaining effort / errors / maintenance / net result including negative].
• Next decision: [continue / repair / revise / stop / owner / review date].

Open the worksheet: Automation candidate and pilot sheetDownload (Markdown)

Sources

Advanced workflows

Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

Source notes: Oct 2026. See method and evidence notes.