Describe the work as it happens today
Record the input, the action or decision, the output and the person accountable for it. Include how often the task occurs, where work waits and what creates rework.
Collect representative examples that can be shared within your organization’s data rules. Include ambiguous and unsuccessful cases, because the easiest examples can give a misleading picture of the task.
Separate rules from interpretation
A step with explicit conditions may fit deterministic automation: the same valid input should follow the same defined rule. A step that requires interpreting variable language or context may be an AI candidate.
Some workflows need both. For example, a hypothetical request-routing process could validate required fields using rules, assess the request’s meaning using AI and ask a person to review unclear cases. This example illustrates a design choice; it is not a delivered project claim.
Define the cost of an incorrect result
Ask what happens if the output is incomplete, incorrect or inappropriate. Can a person catch the problem before it affects a customer or business record? Can the result be reversed?
The consequence determines the review required. A draft reviewed before use has a different action boundary from a system that changes records directly.
Establish the data boundary
List permitted inputs, sources, access roles and output destinations. Identify information the system must not receive and the requirements governing activity records and retention.
These questions belong before provider selection. A technically capable model still needs to fit the organization’s data and operating constraints.
Agree evaluation criteria
Describe what a good output must contain and what would make it unacceptable. Use representative examples and record the reviewer’s decision against those criteria.
Evaluate the workflow as well as the output. Consider how a person receives the result, detects uncertainty and completes the next step. A technically plausible response can still create more review work than it removes.
Choose a narrow pilot
A practical pilot has a named owner, a limited input set, defined review, a stopping mechanism and a period for observation. Agree how manual fallback will work if the system is unavailable or unsuitable.
Measure the operational objective you started with, alongside review effort, errors and operating cost. Decide in advance what evidence would justify expansion, revision or stopping the experiment.
Use a simple opportunity record
Document the task, current problem, proposed AI step, data boundary, unacceptable errors, review owner, evaluation set and next decision. If several of these remain unclear, discovery is the immediate task.
Webseek’s AI-Powered Business Solutions service helps define and implement that scope. Explore our technology categories and automation versus orchestration guide for related decisions. If the system needs to choose and perform actions, continue with the agentic AI readiness guide.