A first initiative needs a recognizable result, accessible data, owners, and execution boundaries. Compare three opportunities and follow the transformation of a broad idea into a scope the team can build and evaluate.
In a conversation about AI, several possibilities emerge: answering customers, preparing proposals, consulting documents, analyzing the operation. All can be relevant. The challenge is to choose which one allows learning from a real problem without starting with a project so broad that no one can tell when the first version worked.
Compare work before comparing technologies
Consider a fictional company that sells maintenance services to other companies. The sales team gathers information to prepare proposals, support answers questions about contracts, and operations tracks ongoing orders. There is interest in using AI in all three areas, but the team available for the first delivery is limited.
Start by describing each opportunity as a job: who requests it, what information comes in, what transformation takes place, and what output someone uses. “Sales agent” still leaves many decisions hidden. “Prepare a draft proposal from a complete request, for sales review” already offers a scope that can be discussed.
This formulation does not choose chat, automation, search, or an agent in advance. A conversational interface may be convenient, but the format should serve the process. First we need to know who will do what and how the result will be used.
Use explicit criteria without manufacturing a certainty score
To compare the opportunities, I propose five questions: does the result have value for someone participating in the project? Can the necessary data be accessed? Is there an owner for the process? Do exceptions have a viable path? Can we check the output before expanding usage?
The table below records fictional conditions at this company. It is not a universal ranking. It serves to show how a conversation based on dependencies helps choose an initial scope.
| Opportunity | Favorable condition | Dependency to resolve |
|---|---|---|
| Prepare draft proposals | A document template and a defined sales review are in place. | Confirm the current price list and required fields. |
| Answer questions about contracts | Recurring questions and a team available to evaluate. | Separate contract versions and access rules by customer. |
| Change ongoing orders | Concrete and frequent operational result. | Define permissions, write integration, and failure recovery. |
In this scenario, preparing proposals seems a viable starting point because there is already a recognized output and someone to review it. That choice would change if prices were scattered or if no one could oversee the review. An unresolved critical dependency can weigh more than the sum of several favorable aspects.
Design the first scope through to the end
Once proposal preparation is chosen, the next step is to define its boundaries. The initiative begins when someone in sales receives a request with the service type, service location, and minimum customer data. The solution organizes this information, consults authorized sources, and prepares a working document.
The initial scope ends when the salesperson receives the draft, identifies the information used, and can approve or correct the proposal. The document is not sent automatically to the customer. Granting discounts, negotiating contracts, and confirming availability remain the responsibility of the people designated in the process.
These boundaries make the proposal evaluable. The team can check whether the fields have been filled in, whether the price source is current, and whether missing data has been flagged. It can also say what the first version does not yet do without treating every new request as a failure of the delivery.
- Input
Request with the agreed minimum data.
- Preparation
Organizing information and consulting sources.
- Review
Salesperson checks amounts, terms, and pending issues.
- Output
Draft approved or returned for correction.
Test dependencies with real examples from the process
Before promising an integration, ask the team to gather examples of requests and proposals it can use in the work. Examine where prices, terms, and service descriptions came from. Find out who updates these sources and how a version ceases to be valid.
Include an incomplete request, a sales exception, and a situation the team decides not to handle. These examples reveal decisions that an ideal workflow often hides. If the customer does not provide the service location, should the solution ask for the information, prepare part of the draft, or refer it to someone? The team needs to choose.
Observed manual preparation can clarify the process before full integration. It allows observation of which information is actually used and what makes a draft useful. This stage does not prove automatic operation; it produces material to specify it and evaluate the version that comes afterward.
Agree on how to recognize a useful first version
An acceptance criterion describes the expected behavior in a concrete situation. For a complete request, the draft should include the agreed fields and references to the information consulted. For an incomplete request, it should indicate what is missing. For an exception, it should refer the decision to the designated owner.
Besides checking the document, observe the salesperson's work. Can they find the points they need to review? Does the proposal reduce any preparation stage or merely shift effort to correcting the text? Does the format fit the workflow the team already uses?
If the intention is to compare time or repeated work, record how the task happens today and keep the scope of the comparison explicit. Simple proposals and exceptional negotiations may require different effort. The initial objective is to understand where the solution helps and where it needs adjustment, without attributing precision to a measure the team does not yet know how to collect.
Choose what to learn before choosing what to expand
The first stage can use one service type and a group of salespeople who participate in the review. Then the team decides whether to expand the catalog, connect another source, or add an action. Each expansion introduces its own questions; a draft reviewed by a person does not demonstrate that automatic sending is already ready.
It is common for the first initiative to reveal a need that precedes AI: organizing the price source, clarifying who approves a condition, or standardizing request intake. Resolving this dependency can be part of the delivery. Planning should make this work visible so that it does not appear as a surprise in the middle of deployment.
If the company already uses AI in this process, start by investigating the current operation. Find out which stages work, what information is available, and where the team loses time or confidence. The first improvement can use existing agents instead of requiring the entire path to be rebuilt.
Questions to discuss with your team
- What output will someone use, and who can say whether it is good?
- Which dependency would prevent the initiative from working, even with a good model response?
- Which decisions and actions are outside this first version?
- What difficult situation will we include before expanding usage?
The first operation should produce a useful result and enough learning for the next decision. Clarity about inputs, owners, boundaries, and acceptance criteria gives the team a concrete basis for building.
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.