When automation is the right answer
Strong candidates
- Repeated work with a stable trigger and clear completion state.
- High volume, measurable delay, or expensive error.
- Inputs and outputs already exist in systems that can be observed.
Leave alone for now
- Rare work where exceptions are the work.
- High-stakes judgment with unclear accountability.
- A process that changes weekly or is broken before digitization.
The automation selection framework
1. Map the actual process, including variants
Documented procedures usually describe the intended flow. Event logs, timestamps, queues, and direct observation show the real one. Map triggers, handoffs, rework, waiting, and exceptions. Measure cycle time and touch time separately. A task that appears to take two days may contain twelve minutes of work and forty-seven hours of waiting for missing information.
2. Score value and suitability separately
Value comes from volume, time returned, avoided loss, faster cash, lower error, and better service. Suitability comes from rule stability, input quality, system access, observability, reversibility, and exception rate. High value with low suitability may deserve process redesign first. High suitability with low value is a harmless demo, not a priority.
3. Separate deterministic work from judgment
Use rules when the decision can be stated and tested. Use a model only when examples show that rules are insufficient and the error trade-off is acceptable. Keep people in the loop where context is incomplete, consequences are material, or the system's confidence is low. The boundary can move over time as the exception log becomes training evidence.
4. Design the exception path before the success path
Automation fails at interfaces: malformed input, duplicate events, rate limits, unavailable systems, ambiguous records, and partial completion. Define what retries, what stops, what reaches a human, and what evidence the reviewer receives. An exception queue needs an owner, severity, service level, and resolution state. Otherwise it becomes a quieter inbox.
5. Engineer for replay and reconciliation
Each step should be safe to retry without creating duplicates. Record inputs, decisions, outputs, and state transitions. Reconciliation checks whether the source and destination agree after the workflow runs. Monitoring should cover lag, error rate, queue depth, and business completion, not just whether the service is online.
6. Prove the change with before-and-after measurement
Baseline cycle time, touch time, error, exception rate, unit cost, and downstream outcome before release. Compare like with like after the change and allow enough observations to distinguish improvement from normal variation. Report labor reallocated, not fictional "hours saved" that never leave a budget or create more useful output.
Automating invoice intake without automating approval
A finance team processes 12,000 supplier invoices each month. The proposed system extracts fields, matches purchase orders, checks duplicates, and routes exceptions. Approval remains with budget owners because contract context and disputed delivery require judgment. Straight-through processing is allowed only when supplier, amount, purchase order, tax, and receipt all reconcile inside defined tolerances.
The first release targets the 62% of invoices with stable structure and clean purchase orders. It measures median cycle time, duplicate prevention, exception rate, and reviewer touch time. The decision to expand is gated on stable reconciliation and a falling exception backlog, not on extraction accuracy in isolation.
Evidence requirements
| Evidence | What it tells you | Warning sign |
|---|---|---|
| Event logs and timestamps | Volume, variants, wait, rework, and bottlenecks | Manual work is invisible or inconsistently logged |
| Exception samples | Where rules break and judgment begins | Exceptions are labelled "other" with no cause |
| Error and loss history | Financial and service stakes | Only easy-to-count errors are included |
| System ownership and interfaces | Feasibility, data contracts, and operating risk | No source of truth for key fields |
| Baseline metrics | Whether the change creates value | Success is defined after deployment |
Failure modes
Automating waste: a broken process becomes faster and harder to change. Happy-path design: the demo succeeds while the exception queue collapses. Invisible manual work: reviewers repair outputs off-system, making quality look higher than it is. Model where rules suffice: uncertainty and cost are added without better outcomes. No idempotency: retries create duplicate records or payments. Vanity ROI: theoretical hours are counted without showing what capacity was actually released.
Automation readiness checklist
- The current workflow is mapped from observed events, not only interviews.
- Value and automation suitability are scored separately.
- The rule, model, and human-review boundaries are explicit.
- Every exception has a route, owner, service level, and resolution state.
- Retries are safe, decisions are logged, and systems reconcile.
- Baseline and release metrics include business outcomes and quality.
- There is a rollback path and an owner for ongoing operation.
Limitations
Automation can shift work rather than remove it, especially when upstream data quality is weak. Historical event logs may omit the informal coordination that keeps the process functioning. A reliable solution also needs operating ownership after launch. If the economics depend on eliminating roles rather than improving capacity, validate the full organizational change instead of treating software output as realized savings.
Related services and cases
Automate the right boundary
We can identify the first workflow worth automating and build the measurement into it.