Follow a real case from start to finish
Ask an employee to show you how a recent case was handled. Start with the event that triggered the work, then follow every system, document, conversation and judgement until the result was used or sent. A specific case reveals more than a general description of the official procedure.
Record the workarounds too: the spreadsheet somebody created, the colleague everyone asks or the document that needs double-checking because it is often out of date. An AI system based only on the formal process may miss how the work is actually done.
Name the sources and the judgements
Write down the information the employee needs at each point, where it comes from and how they decide whether it can be used. Distinguish between fixed rules, current specialist content, details about the case and experience that is not recorded in a system.
- Start.What triggers the work, and who receives the case?
- Sources.Which documents and systems are used, and who keeps them current?
- Judgements.Which choices require expertise or authority?
- Result.What is produced, who uses it and what happens next?
Define exactly what AI should help with
Describe the information the system will use and what it should produce. It might use a question and a set of approved manuals to draft an answer with links to the relevant passages. The system must not approve the case, alter customer data or send the answer.
If you cannot explain the AI component in one or two sentences, the use case is probably too broad. Break it down until you can test a distinct function without building the rest of the system at the same time.
Describe what happens when the system cannot answer
Decide how the system should respond when sources are missing, information conflicts or the user asks for something outside its remit. It can request more information, show that sources disagree or pass the case to a particular employee or specialist team.
The employee checking the output must see the sources and be able to correct or reject the suggestion. An approval button is not enough if that person lacks the information required to spot an error.
Use the description to plan the prototype
The description gives you concrete examples to test, a list of sources and permissions and an overview of what the interface must show. It also reveals which questions security, privacy or legal specialists need to consider.
I can map the work with your employees and use the description to build a prototype they can try. We can then test how the system performs within the real job, using the right sources and checks.