Choose a task the team recognizes, find an observable outcome, and define who takes over when the first version reaches its limit. By the end, you will have a scope that can be discussed with business and technology teams.
Map the beginning and end of the task
Invite someone who does the work and ask them to describe a recent instance, from the initial request to delivery. Record what triggered the task, what information arrived, who needed to participate, and how the team knew it was finished. Avoid starting from a list of features: “prepare a quote for sales review” allows you to discuss limits that “create a sales agent” leaves open.
Choose one part of that sequence. If preparing the quote depends on terms the salesperson is still negotiating, the first version can organize the data and deliver a draft. Explicitly note the decision that remains human. The scope should fit into an explanation that people from different departments understand in the same way.
Choose the outcome and the point of comparison
Ask what needs to improve in this task: less waiting, less repeated data entry, more complete information, or greater continuity through to the next stage. Choose one main measure and record how it will be observed. If the problem is the time until the quote is ready, measuring only messages answered does not answer the question.
Gather examples of the current process and identify their conditions: request type, channel, and team involvement. When no reliable measure exists, the first task is to build that baseline. Record “to be measured” instead of estimating savings and treating them as a result. The team needs to agree on what a completed task means before comparing performance.
Check context, access, and exceptions
List the sources a person consults and the systems they work in. For each item, note who maintains the information, how the solution will be able to access it, and what happens when it is missing or outdated. Distinguish looking up a table, preparing a document, and changing a record: each action may require different authorization.
Choose examples that reveal limits, such as an incomplete record, a request outside the rules, and an unavailable integration. Define whether the solution should ask for clarification, prepare a pending item, or hand off to someone. The first version does not need to resolve every exception; it needs to recognize them and give a clear destination to work that cannot continue.
Agree on how to test and decide whether to expand
Assemble a set of representative situations, including the selected exceptions. For each one, write down the expected outcome and who will check it. Start with data and an environment appropriate for the test; using the real channel, accessing real information, and sending messages are decisions that need to be agreed with the people responsible.
When reviewing the first version, observe both what it did and what it did not do. Was the deliverable usable? Did the team understand the pending issue? Was a person able to take over? Record what needs to change before expanding use. The next decision may be to move forward, narrow the scope, fix a dependency, or keep the work with the team while the necessary condition is not in place.
Illustrative example · no customer data
Prepare a quote without automating the entire sale
Illustrative example: a team receives requests through the website and repeats data collection to use a quoting tool. The chosen scope is to gather the required fields, look up the authorized options, and prepare a proposal for review. Negotiating terms and closing remain with the salesperson.
The team compares whether proposals arrive complete and how much time passes between the request and the material being ready. An incomplete record prompts a question; terms outside the rules create a pending item for the salesperson. The first test ends with a proposal that can be reviewed, not with the promise of a sale.
When the approach needs to change
If the data is not organized, start by preparing the material. If the integration does not yet exist, test the flow with representative data and record that dependency. If no one can check the outcome, first find someone responsible: autonomy without monitoring does not solve the lack of ownership.
A point to watch: Expanding the scope to several journeys before knowing how the first one will be monitored.
The worksheet is ready to move forward when…
- The task has defined inputs, outputs, and human decisions.
- There is an observable measure or a plan to create the initial baseline.
- Sources, exceptions, responsible people, and test criteria are recorded.
Use the guide to discuss the first initiative. Also bring an example of the current work and a situation in which it cannot proceed normally.
Your worksheet
Complete it with your team.
Record what you know and what still needs confirmation. Answers stay in memory and are not submitted.
References for further reading
- NIST AI RMF Playbook · Measure 1.1 and 1.2 ↗
Provides guidance on choosing measures appropriate to the context, documenting what was not measured and reviewing the assessment when conditions change. It is an evaluation reference; the examples and criteria in this material are proposed ways of working.