We order real workflows by effort, data risk and feasibility. The result is a sequence that can be explained and decided internally.
| Use case | Value | Data | Effort | Next test |
|---|---|---|---|---|
| Email triage | 4/5 | 2/5 | 2/5 | Label 50 cases |
| Quotation draft | 3/5 | 4/5 | 4/5 | Clarify approval path |
| Call intake | 4/5 | 3/5 | 3/5 | 20 test calls |
| Internal search | 2/5 | 5/5 | 4/5 | Inventory the sources |
Test email triage first. The volume is visible, the result can be checked and the change to the existing workflow remains limited.
Not every laborious workflow is a good AI use case. Clearer responsibilities, cleaner data or a small process change may need to come first.
A manual check may remain more economical and easier to understand.
Automation also speeds up wrong or outdated information.
Without an owner, every exception stalls, regardless of the tool.
The process then needs a human review point in the middle.
We agree the scope before the workshop. This example shows the format, not a blanket service promise.
A shortlist, risk register, test plan or technical handover: before the meeting, we decide which document will actually support your decision.
No automatically generated “AI score”.
The starting point is a real workflow, not a tool. We record how often the case occurs, how long it takes, where waiting time appears and which exceptions the team currently resolves by hand. This includes the people involved, the systems they use and the person who remains accountable for the outcome. Only that baseline can show whether a change saves time or merely moves work elsewhere.
Each possible AI use case is then reviewed against the same criteria: business value, data availability and quality, technical feasibility, consequences of errors and the human handovers that remain necessary. Assumptions are written down. We do not present a precise ROI when reliable volumes, costs or comparison values are missing. The early assessment stays honest while still being useful for a decision.
The result is an argued order of priority. It distinguishes what can be tested now, what first needs better data or clearer ownership, and what should deliberately remain manual. For the leading candidate, we define the test boundary, required access, privacy and retention questions, and review points. For a Swiss SME, understandable data paths and named responsibility matter as much as the model itself.
A pilot therefore starts narrow and ends with a real decision. Baseline, target, owner and review date are agreed before work begins. Afterwards, the question is not only whether the technology ran, but whether the entire workflow became more reliable, faster or easier to understand. The documented outcome is to continue, change or stop—not to keep a demonstration alive without evidence.
Bring one typical process and one difficult exception. In the call, we clarify which data are missing, where a person must decide and whether a pilot makes sense at all.