Before choosing a model or building a pilot, follow one piece of work through the team. An invoice, a support request, or a weekly report is a useful starting point because you can see where it arrives and what happens next.
Talk with the people who handle it. The written process may leave out the steps that take the most judgment or time.
Map the ordinary case and the exceptions
Record the inputs, systems, decisions, and handoffs. Ask what happens when information is missing, a request is unusual, or the person who normally handles it is unavailable.
Those exceptions matter to the pilot. A system that handles ordinary cases well still needs a way to recognize and route the others.
For an order-to-cash process, for example, classification is only one step. Someone must review uncertain cases, decide whether to use a draft response, and record the outcome in the business system.
Decide where an AI result would go
Describe who will receive the output and what they will do with it. Identify what they need to check and when they should escalate a problem.
If nobody can use the result without reconstructing the work, the pilot may not save much time. You may need a different output, better integration, or a smaller task.
Choose a measure the team can use
Technical tests help assess whether the system produces suitable output. Operational measures help assess whether the changed process is useful. You need both.
Depending on the task, useful measures might include time to resolve a request, correction effort, cost per transaction, or missed deadlines. Record the starting point before the pilot so you can compare results.
Agree on ownership and scope
Name the person responsible for the process and the people supporting the system. Agree on the test period, the cases it covers, and what would cause you to pause or change the approach.
Keep the first trial small enough to learn from. If the mapping reveals that better documentation or a simpler integration would solve the problem, that is a useful finding too.
At Joust, this work can be part of an assessment or the planning for a build. Tell us about the process you are considering, and we can discuss an appropriate scope.
Ron Davis
Founder
Three decades building enterprise platforms. Started Joust to close the gap between strategy decks and the work they're supposed to change.