Workflow design / Choosing a first pilot
How to choose the first AI workflow.
Choose a recurring task with a responsible owner, information you can use and a result you can check. Decide what should work better before selecting a model.
This is the starting point for our Forward Deployed Engineering approach: understand the work before building the system.
1. Describe the work before proposing AI.
Watch someone complete the task today. Record what starts it, who does it, which information they need, what they produce and who uses the result. Include waiting, corrections and exceptions, not just the ideal sequence.
Turn “we need an AI assistant” into a specific statement: “A sales colleague needs to prepare a product answer from approved documents, have it reviewed and record the follow-up.” This gives a pilot a beginning, an end and someone to help.
2. Check six conditions.
- A recurring problem
- Find work that happens often enough to observe. A memorable one-off inconvenience may not justify a system.
- Known users
- Name the people doing the work and involve them in defining a usable result. Support from management matters, but you also need time with the people doing the task.
- Accessible, approved data
- Identify sources, permissions and the person who can resolve missing or conflicting facts. Resolve missing access or unreliable information before working on prompts.
- An internal owner
- Someone on the customer side must make decisions, resolve process questions and own the workflow after the pilot.
- An observable result
- Decide how to compare the current and proposed process: completion, total time or hands-on time, corrections, omissions, or an agreed quality check.
- A clear scope
- Choose one task, a defined user group and a controlled set of systems. State which actions the pilot cannot take.
If an essential condition is missing, resolve it or select another workflow. A sophisticated demo does not remove a missing owner or inaccessible data.
3. Check whether simpler options are enough.
Check whether a clearer process, a shared template or an existing product can solve the problem. Use ordinary rules for steps with fixed inputs and predictable results. Consider AI where interpretation, retrieval or drafting is useful, and test whether its output can be evaluated and corrected.
Custom development needs a reason: an integration, constraint or workflow that simpler options cannot serve. The pilot should also account for the effort of review and upkeep.
Illustrative scenario · Not an executed pilot
Example: draft a product answer for sales review.
This example illustrates scope only. It describes no existing customer deployment or measured result.
For other starting points, explore business workflow examples across sales, marketing, customer service and operations.
- Trigger and users
- A salesperson receives a product question. The first pilot covers one approved product range and a small, agreed user group.
- Input
- A question with unnecessary personal or confidential details removed, plus approved product documents with named owners and versions. Use only data permitted for the selected system.
- AI contribution
- Retrieve relevant passages and draft an answer with references. Flag missing information instead of filling gaps with invented specifications.
- Human control
- The salesperson verifies the answer before sending. Pricing, discounts, suitability and contractual promises require the relevant business approver.
- Integration
- Start with approved document access and a human-reviewed answer in the existing sales process. Only add records automatically to the customer relationship management system (CRM) after testing permissions, duplicate handling and recovery.
- Out of scope
- Automatic customer sending, autonomous pricing and unrestricted access to unrelated company documents.
- Deliverables
- A usable review step, source register, evaluation examples, operating guide, fallback procedure and clear maintenance ownership.
4. Decide what to measure and when to stop.
Before using the proposed system, observe comparable work in the current process. Record the same measures for the pilot, including time spent reviewing or repairing its output. Define acceptable quality and the sample and observation period with the business owner before interpreting results.
For the illustrative sales workflow, proposed checks include an unanswered question, contradictory product documents, a revoked permission and a service outage. The system should explain the problem and direct the user to the agreed manual process. These are proposed acceptance checks, not completed test results.
Pause or narrow the pilot if sources cannot be trusted, review burden outweighs the benefit or a required approval can be bypassed. A decision not to deploy is a valid outcome.
5. Observe use, then decide.
Help users complete real tasks and show them how to reject an answer, correct a source and recover from failure. Record why they use the system, avoid it or revert to the previous process. After training, check whether people actually continue using the system.
Review three separate records: functionality that passed deployment checks, usage observed in normal work and outcomes compared with the agreed baseline. Do not turn one into evidence of the others.
Before expanding, name the people responsible for source updates, permissions, technical incidents and future changes. Decide whether to stop, improve the bounded pilot or move it into normal operations. Expansion should follow evidence.