Choose a frequent, understandable workflow with a clear owner, accessible inputs, a measurable baseline, and a manageable failure path. Start where you can evaluate the result, not where the demo looks most impressive.
Compare candidates using the same questions
A team may suggest invoicing, dispatch, document review, lead follow-up, and reporting at once. Before comparing technology, compare the work: how often it happens, how many handoffs it needs, and what a mistake would affect.
Our recommendation is to shortlist two or three processes and walk through a recent example of each. A process that cannot be explained consistently may need an operational decision before it needs automation.
These are hypothetical scoping examples, not client results or a ranking of the most profitable automations. Compare a normal case and an exception for each candidate. A frequent task with unresolved access or ownership can be a worse first pilot than a smaller task the team can verify end to end.
| Candidate | Evidence to inspect | Small first scope | Reason to pause |
|---|---|---|---|
| Route incoming service requests | A recent request, the required fields and the person who assigns it. | Create one reviewable task from a complete request; send incomplete requests to the coordinator. | Nobody owns requests that fail to reach the destination. |
| Prepare supplier documents for review | A document, its matching order and an example of a missing or conflicting field. | Extract a draft record and show the source to a reviewer before changing approved records. | The team cannot trace extracted values back to the original document. |
| Assemble a recurring operations report | The current report, source exports and the definition of each total. | Prepare one report from a fixed reporting period and reconcile it with the manual version. | Source systems use different definitions and no owner can reconcile them. |
Name the person who owns the result
The pilot needs an owner who can describe exceptions, review the proposed behavior, and decide whether the result is useful. A sponsor can approve spending, but the person responsible for the workflow supplies different information.
For an illustrative service request pilot, the owner might be the coordinator who assigns work every morning. They can identify why a request gets delayed and which details the team repeatedly has to chase.
Check the inputs before promising automation
Determine where the required information comes from, whether the team can access it, and how reliably it arrives. A well-defined process can still be a poor first pilot if the necessary system cannot provide an export or suitable integration.
If documents or messages need interpretation, separate the part that retrieves information from the decision that changes a business record. AI might assist with one step without owning the entire workflow.
Measure the work before changing it
Choose a baseline that the business can actually collect. Examples include time until assignment, number of manual handoffs, or requests still unresolved after an agreed period. Use a representative period and note unusual conditions.
Do not treat a demonstration with synthetic records as evidence of a measured business improvement. A demo can validate behavior; an operational pilot needs real use and a consistent definition of the outcome.
Here is a worked example for routing service requests. All figures are hypothetical monthly values, not AgenticShip client results. Keep review, exception handling and maintenance separate so that the same work is not counted twice.
The 21 hours represent potential capacity, not an automatic reduction in payroll or a cash return. The investment decision must also account for implementation, subscriptions and the value of work the team can actually take on. If the monthly volume halves, and review and exception effort halve while maintenance stays at two hours, the same example releases 9.5 hours, not 21.
| Effort measure | Assumption or calculation | Hours per month |
|---|---|---|
| Current manual work | 300 requests multiplied by 6 minutes, divided by 60. | 30 hours |
| Routine review after automation | Check that normal requests were routed correctly. | 4 hours |
| Exception handling | Resolve missing details and failed handoffs; exclude routine review already counted. | 3 hours |
| Ongoing maintenance | Review mappings and keep the connection working. | 2 hours |
| Remaining operating effort | Add review, exception handling and maintenance. | 9 hours |
| Potential capacity released | Subtract the 9 operating hours from the 30 manual hours. | 21 hours |
Define the exception route
Write down what happens when information is missing, a tool is unavailable, or the proposed action needs a person’s judgment. Someone should be able to see the unfinished work and take over.
A pilot can deliberately keep a human approval step. The question is whether that step has a clear purpose and enough context for the reviewer. Moving all uncertainty into an unexplained approve button does not resolve it.
Agree on the decision after the pilot
Set a review point and decide what would justify expanding, adjusting, or stopping the workflow. Include operating effort: if staff spend substantial time correcting outputs or maintaining the integration, that work belongs in the assessment.
The first pilot should teach the business how to evaluate an automated process. A modest workflow with visible results provides a stronger basis for the next investment than an ambitious demonstration that nobody owns after launch.
At the review, replace every assumption in the table with an observation from the pilot. Expand only if the useful outcome survives that substitution and exceptions remain manageable. A pilot that saves time but creates untraceable missed requests has not passed the same business test.
Bring the candidate that passes this check to a workflow automation fit conversation, together with a redacted example and the tools involved. The service page explains the scope and handoff; the ROI guide below helps evaluate a pilot after real use.