Reconstruct the process as it works today
Before discussing technology, follow a real execution and identify inputs, decisions, outputs and exceptions. Compare the written procedure with what the team does when information is missing or something becomes urgent. That difference reveals knowledge that needs to be made explicit and helps select a sufficiently bounded task for initial work.
The person may choose a document version because they recognise the customer's name, even though the procedure simply says to open the proposal. They may also ignore a field because they know that offer no longer uses it. Without that explanation, the next person will have to rediscover the difference.
A useful playbook combines the objective, steps and lessons to support continuity within the team. When preparing it for automation, add what each decision consults and how it can be confirmed. Choosing the appropriate offer needs to become concrete questions about the need, scope and available conditions for that particular request.
Do not immediately convert every observed choice into a rule. Some may result from a personal habit, an old exception or information that has already changed. Confirm with the process owner which criteria remain valid before fixing them into an execution that will be repeated across future cases.
Check data and evaluation capacity
Readiness depends both on available information and on someone being able to recognise an appropriate answer. Gather examples, check their currency and identify who can validate the output. If data or criteria do not yet exist, turn that absence into a concrete preparation task before expecting AI to resolve the uncertainty.
Consider a pilot that turns an authorised meeting transcript into a summary for the team. For the meeting example, you need an authorised and sufficiently complete source. The reviewer should know which decisions were made and recognise when a suggestion has been mistaken for a commitment. Without that reference, a well-written list may look useful while assigning responsibilities that nobody actually accepted.
Choose representative examples from normal work. Include a straightforward case and another in which the information is less organised. The test should show how the system responds to the variation the team encounters rather than depending entirely on the easiest example available to prepare for the demonstration.
Check what may be used in the experiment too. Customer data, internal messages and third-party documents require attention to access and context. Clearly identified fictional data can help test the initial structure before real, authorised information is introduced into the working process and assessed by the responsible person.
Data availability also means being able to find and understand it. If the project begins with several weeks of reconstructing scattered archives, that preparation is part of the scope. Recognise it early and decide whether a different pilot could produce useful learning with fewer dependencies.
Define what requires a human decision
Classify proposed actions by their effects, the possibility of correcting an error and the information needed to decide. A useful assessment states where AI only prepares work and where it may execute. The boundary should be understood by process users, including what happens when a situation falls outside the agreed scope.
For sales support, the assistant might prepare a summary, the salesperson check the enquiry and a manager approve a special condition. That division should match the company's real process. Adding AI does not automatically give the person configuring the tool authority to change commercial rules or commitments made to customers.
Defining who approves each part of an automation project helps avoid unclear responsibilities. If a result reaches a manager without indicating whether it has been checked, they may assume a review that never happened. The status of each piece of work needs to travel with its content.
Set aside time for this initial review. Giving people tool access while retaining the same workload may encourage rushed acceptance or cause the test to be abandoned for lack of availability. The pilot needs room to observe, correct instructions and discuss cases where a response sounds convincing but does not serve the task.
Assign responsibility for operation
A business is better prepared when someone owns monitoring the process’s usefulness, failures and necessary changes. That person needs access to information and the ability to request corrections or stop execution. The assessment should make these conditions visible instead of assuming that responsibility belongs to the tool or disappears after implementation.
A technician can confirm that a flow ran without error while still being unable to judge whether a customer response made sense. The process owner needs to understand the intended result, current rules and situations requiring attention. Their assessment includes the content and consequences of the execution, alongside its technical completion.
In a hypothetical proposal preparation process, the owner might be the person who knows the services, approved prices and delivery boundaries. A failed connection between systems requires technical help. A proposal using an outdated condition requires the owner to identify which rule needs revision and what the correct condition should be.
Defining who approves each part of a project helps establish this relationship. After launch, responsibility should remain visible so the team knows who decides without needing to locate whoever originally built the first version or remember an informal conversation from implementation.
Choose a pilot and continuation criteria
Close the assessment with a bounded task, test examples and a comparison with the current way of working. Observe quality, total effort and ease of correction, including human review. I do not assign a scientific maturity score to this conversation: I look for concrete conditions for deciding whether the pilot should proceed, change or wait.
For the chosen example, check whether all decisions were preserved, task owners were identified correctly and unresolved questions were marked as such. These criteria are more useful than simply asking whether the text looks good. The assessment stays connected to the function the summary is meant to perform.
Record corrections briefly and distinguish content errors from presentation preferences. A long sentence may be easy to shorten; a responsibility assigned to the wrong person requires a correction in meaning. The team needs to understand which mistakes restrict use and which can be handled through a simple editing step.
Observe the correction process itself. If the reviewer can amend the draft and proceed, there is a straightforward recovery path. If they must return to the source and redo the entire task, the advantage may disappear even when most individual sentences are well written and appear plausible.
Keep comparison with the previous process proportional to the experiment. A few cases can reveal problems and inform the next test, but they do not justify turning an early impression into a dependable forecast for the whole business. Record what you observed and what still needs to be tried.
Prepare your enquiry with a real input and output example, task frequency, tools used, owner and current difficulty. The broader context is covered in AI for business owners; process design continues in business process automation. If you need implementation support, introduce the context to the team through the contact form. If your priority is choosing among business opportunities, describe that decision in an individual mentoring enquiry.