In this note
“Find us an AI use case” is a difficult assignment to start from. You can interview a few executives, collect their wish lists, and finish with ten projects nobody has time to own. I’d rather ask someone to show me the last piece of work they sent back for correction.
Follow that case. What arrived? Who checked it? Which system held the answer? Who waited? What finally counted as finished? You’ll usually have better questions after that conversation than after a product demo.
Agree what you can inspect
A procurement lead agrees to inspect domestic purchase requests for existing suppliers, from arrival until a buyer accepts them. We leave new suppliers, international orders, and restricted purchases for another investigation. That gives us a queue small enough to follow.
Agree what you may open and record first. Here, the owner permits a read-only walkthrough of redacted requests in an approved workspace. We can record references, relevant fields, versions, and questions. We cannot change a request, copy another queue, or upload documents to a model provider.
Choose 10–15 recent cases. Include a routine completion, a correction, something still waiting, and an important exception the owner identifies. Note how you chose them. Twelve requests may reveal a missing field or unexpected handoff, but cannot tell you how often it happens across the company.
Trace arrival through acceptance
In request P-41, the manager supplies the supplier ID, item, quantity, delivery date, and cost center. A coordinator checks them, attaches the current supplier record, and sends the request to a buyer. The buyer accepts it for order preparation. We stop following this case there; no order has been placed or paid.
- Request arrivesThe manager submits P-41 in the request queue.
- Coordinator checks itRequired fields and the supplier reference are present.
- Evidence is attachedThe coordinator links supplier revision S-12.
- Buyer receives itThe buyer inspects the request and attached evidence.
- Acceptance is recordedThe buyer accepts P-41 for order preparation; no order is placed here.
P-47 has no cost center. The coordinator asks for it by email, then copies the reply into the queue. The buyer sends the request back, saying the cost center is closed. The process diagram says “check fields, send to buyer.” It leaves out both the email chase and the return. We still need the source owner to confirm whether the cost center is closed.
Use the queue history to check when the request arrived and came back. Use the email to see what the requester supplied, and ask the coordinator why they copied it. If you cannot access the mailbox, leave that part unknown and request an approved redacted example.
Keep four kinds of answer separate
| Claim | What the evidence establishes |
|---|---|
| Stated: “Requests are checked before the buyer sees them.” | The coordinator reported this practice in interview I-1. It does not show that every request follows it. |
| Observed: the buyer returned P-47, citing a closed cost center. | The inspected queue history shows this return in P-47. The source state and frequency remain to be checked. |
| System-enforced: the coordinator’s handoff requires a nonempty cost-center field. | A permitted check of form configuration Q-3 establishes a presence check. It does not establish that the value is current. |
| Policy-authorized: the buyer must accept a request before order preparation. | Policy PR-4, confirmed by its owner, requires this approval within the stated domestic-request scope. It does not prove consistent execution. |
Keep those answers separate. A workaround the coordinator shows you may still break policy. A field the form accepts may still contain a closed cost center. Record the source and owner of each claim so the next person can check what applies.
We now have a question worth investigating: could the coordinator catch missing or invalid cost centers before sending requests to the buyer? To test it, we need the official cost-center source, permission to use it, a baseline, and someone who can check the result. We have not established that most requests are wrong or that software should approve purchases.
Talk to the people on either side
Ask a requester to complete a recent case with you. Where did they find the cost center? Did the form help them choose it? Here, the requester blames an old value in a saved template. Inspect the template before recording that explanation as a cause.
Then ask the buyer downstream to show a request they accepted and one they returned. What evidence was missing? What would make a prepared request usable? Would another automated message reduce work or create another inbox to monitor? The buyer may need a current source reference and a clear unresolved question more than a longer summary.
Find out who gets called when the normal path fails. Include that person, the owner who can permit a test, and whoever will check the result. They may know more about this queue than the sponsor who requested an AI project.
Leave with a question and a next decision
I’d take the cost-center question to the source owner next. Which record is official? Can a permitted lookup distinguish current from closed values? The buyer can help define what a usable request must contain. We can investigate those questions while leaving the queue and approval process unchanged.
You may find that repairing the saved template or adding a deterministic lookup removes the repeated chase. If free-text descriptions remain difficult, evaluate that separate interpretation task later. Record the alternative before choosing a model. You haven’t wasted discovery time if the right change needs no AI.
If the source owner cannot permit the lookup, record what is missing and who can resolve it. Keep the current queue while you wait; a redacted sample or a narrower set of requests may let the investigation continue. Agree when to revisit the question. Stop this proposal if the lookup is prohibited or would not help the coordinator and buyer. Any pilot still needs separate approval.