Observe how the work actually flows
A process map should match actual work. Review inputs, ownership, waiting time, exceptions and outputs with users. Sometimes the primary problem is an inconsistent definition or late access to information, which an AI model alone cannot solve. Begin by asking which decision or information handoff causes the most friction and what should improve if it changes.
Define a baseline and acceptance criteria
Record a sample of current performance before changing the workflow: handling time, rework, errors, manual effort and final outcome. Define measures with units and a clear scope. Average time can mislead without understanding the workload and its exceptions. Acceptance criteria should include quality and risk so that speed does not come at the cost of errors or essential controls.
Combine rules, automation and AI appropriately
Deterministic rules may be better served by simple workflows and validation. AI can assist with text, knowledge retrieval and recommendations that need evaluation. Connect model outputs to a defined stage and specify what happens when there is an error, ambiguity or missing data. Keep the pilot reviewable alongside the human workflow and define authority before automating sensitive decisions.
Test the change within a bounded scope
Begin with one request type or user group. Evaluate typical and difficult cases separately and compare results against the same baseline. Record rejected recommendations and manual fallbacks, because they inform improvement. Expansion should follow evidence, data readiness and user adoption. A bounded, evaluable experience provides a stronger foundation for organisational change.
Illustrative example: handling an internal request
Imagine a department receiving requests through several channels. Specialists read the text, identify missing information and assign an owner. First standardise the request form and identifier; this does not necessarily require AI. Then test classification suggestions or text summaries as a separate step. Specialists must be able to edit suggestions, and ambiguous requests should go to human review. Recording each stage and its timing reveals whether the main delay comes from reading, approval queues or missing information. This is a generic workflow-design example, not an account of Roham client work.
Write a pilot evaluation sheet before starting
The evaluation sheet should define the task, unit, sample scope, exceptions and recording owner. Replace vague improvement goals with concrete comparisons: receipt-to-response time, returns for correction, requests requiring manual fallback, or unsupported answers. Agree on the recording source and acceptance condition for each measure before testing. If workload or request types differ between periods, do not directly attribute the outcome to the new system. The goal is to understand actual workflow change rather than display an attractive number without context. Expansion should depend on quality, data readiness and employee adoption.