Agree on the scope and the baseline
Define the inputs, accepted outputs, systems of record and actions in scope. Document interfaces that are available today and work that would need to be built. Identify the business owner, integration owner and reviewer who can accept the result.
Capture the current process on a representative workload. Include existing automation, case volume, elapsed time, staff effort, errors and operating costs. Do not use a deliberately weak baseline to make a proposed model look better.
- Which cases are eligible, and which are excluded?
- What evidence makes a result acceptable?
- Which actions need a person to approve them?
- What data can leave each system, and where may it be processed?
Write an acceptance scorecard before the experiment
| Measure | Required decision |
|---|---|
| Quality | Allowed error categories, rejection criteria and review method. |
| Latency | Median and p95 accepted completion time, plus timeout limits. |
| Economics | Complete cost per accepted case and useful-capacity assumptions. |
| Permissions | Allowed actions, approval boundaries and denied-action behavior. |
| Recovery | Retry budgets, reconciliation and the point at which a person takes over. |
Thresholds belong to the customer's workload. This guide does not prescribe a universal accuracy percentage or latency target. Record sample size, case mix and limitations with the results.
Evaluate normal, difficult and interrupted work
Begin with an isolated evaluation where possible. Compare the current process, a simple model path and the proposed routing design under similar conditions. Keep a held-out evaluation set and document changes made during tuning.
Include incomplete inputs, provider interruptions, permission failures and uncertain action outcomes. A demonstration that succeeds on a few selected examples does not establish reliable production behavior.
Review cases that fail as carefully as those that pass. Track human review time, context loss, duplicate attempts and unplanned manual work. Use the failover checklist and latency measurement plan to structure the evidence.
Make a written stop, revise or expand decision
The final review should include the measured baseline, evaluation results, full costs, unresolved risks and the support required to operate the workflow. If quality or permission boundaries fail, revise the design before using a positive financial estimate to justify expansion.
Steprill's indicative pilot is a 4–6 week engagement for one agreed workflow, with a $10,000 planning fee subject to scope and agreement. A production module, supported connectors, deployment and operating terms require separate validation and a scoped agreement. Review the planning options.
The available company dashboard supports administration and assignments. It is separate from the proposed AI optimization engine. See workspace security and pilot requirements for that distinction.