A business owner finishes a promising conversation about automation. The possibilities sound familiar: less time copying information, faster document review, fewer missed handoffs. The next proposal offers an AI assessment.
Before agreeing, the owner has a practical question: what will the team be able to decide when that work is finished?
A useful answer describes the written outputs, the people who need to contribute, and the limits of the work. A list of tools or a presentation of possible use cases may start a conversation. The assessment should also help the business choose a manageable next step.
Start with a decision the business can make
Choose a question narrow enough to answer with the information available. For example: should the team pilot assistance with preparing customer-service replies, and under what conditions?
That question gives the review a boundary. It calls for an understanding of the current work, the information employees use, the consequences of a wrong reply, and the person who will check the result. It does not require a plan to automate every department.
Ask the provider to connect each proposed output to this decision. If a document will not help someone choose, scope, or govern the next step, clarify why it is needed.
The conclusion should allow for several outcomes. A bounded pilot may be reasonable. Existing software may already solve the problem. Missing access permissions or inconsistent records may need attention first. Deferring a poorly supported use case can be a useful assessment result.
Get a shortlist with reasons
A shortlist is more useful when the reader can see why one workflow was selected and another was deferred.
For each candidate, ask the review to describe the task, the person responsible for it, the systems involved, and the problem the team is trying to improve. Separate observed facts from estimates. If no one has measured how long a task takes, record that as an open question rather than presenting a savings forecast as a finding.
Include the difficult parts of the work. A document process may involve routine forms as well as missing pages, conflicting instructions, and customers who send corrections. The people handling those exceptions often know constraints that are absent from the official process description.
This does not mean every assessment must produce a detailed process map for every candidate. Agree how many workflows are in scope and how deeply each will be examined before the work begins.
Make the data and risk review specific
“Uses company data” is too broad to support a pilot decision. Identify which records are needed, where they are held, who can authorize their use, and who should be able to see the output.
A practical review should make unresolved questions visible. Can the relevant information be accessed through an approved method? Does the team have suitable examples for evaluation? Would the proposed service send information to another provider? Are there records that should be excluded? Which decisions must remain with a person?
The answers depend on the workflow and the services involved. The assessment scope should say whether it includes a technical inspection, interviews, document review, or some combination. A discussion of intended controls is different from verification that those controls are configured and working.
Where specialist review is needed, identify it and assign the next step. Do not treat an assessment as a legal opinion, a certification, or blanket permission to use every available record.
Define what a pilot would actually include
A recommended pilot scope should be understandable to the business owner and useful to the delivery team. Ask for the proposed users, the workflow boundary, the information needed, and the intended output. Specify whether the pilot would only suggest or draft something, or whether it would take action in another system.
Also identify exclusions. An initial pilot might prepare draft replies for staff review while leaving account changes, refunds, and external sending outside its scope. Those boundaries affect access, testing, oversight, and the implementation estimate.
Agree what will be measured against the current process. Time spent checking and correcting results matters alongside time spent producing them. Define who will review the evidence and decide whether to continue, change the scope, or stop.
The assessment may recommend these measures without running the pilot. Keep that distinction explicit in the proposal and final handoff.
An example of a written decision
Consider this illustrative customer-service scenario, not a SAGEN client case.
The proposed first step is to test draft replies for a limited set of routine requests. Staff would review every draft before sending. Account changes and refunds would remain outside the pilot.
The business owner would need an approved set of example requests, access to current response guidance, and a reviewer who understands the exceptions. Before implementation, the team would resolve which records can be used and whether the selected service fits the approved data-handling requirements.
The pilot would compare staff effort and the corrections required with the current process. A named owner would decide whether the results justify continuing. No savings estimate would be presented as proven before those measurements exist.
That is enough detail to discuss a next step without pretending that the system has already been designed, built, or validated.
Ask three questions before buying
What decision will this assessment help us make? Ask for the business question and the limits of the review.
What written outputs will we keep? Clarify the format, level of detail, assumptions, unresolved questions, and any dependencies the team must address.
What is outside the engagement? Confirm whether implementation, configuration changes, pilot operation, ongoing support, and specialist reviews are included or require separate agreement.
A clear proposal also states what your team must supply. Make time available for the people who understand the work, provide approved information, and identify who can make the final decision. Otherwise, the assessment can end with unanswered questions that were predictable at the start.
A focused starting point with SAGEN
SAGEN’s AI Opportunity and Security Assessment covers a use-case shortlist, a data and risk assessment, and a recommended pilot scope. The engagement scope and responsibilities should be agreed before work begins.
If you are considering a first pilot, bring the workflow you want to improve and the constraints your team already knows. Review the assessment to discuss whether it is the appropriate starting point.
Frequently asked questions
What decision will this assessment help us make?
Ask for the business question and the limits of the review.
What written outputs will we keep?
Clarify the format, level of detail, assumptions, unresolved questions, and any dependencies the team must address.
What is outside the engagement?
Confirm whether implementation, configuration changes, pilot operation, ongoing support, and specialist reviews are included or require separate agreement.