AI process discovery: start with the data you already have
AI process discovery from email: how embeddings and clustering sorted 5,483 emails into 25 request types and chose a pilot without weeks of interviews.
A US property management company we work with receives homeowner questions in one shared mailbox: late fees, payment authorizations, statements, dues and many other requests. Mapping that inbox the usual way would have meant weeks of interviews with the staff who answer it, the same people the business could least spare. We asked for the emails instead.
When a process runs through email, the record of how it works already exists. AI process discovery reads that record and shows where the volume and the effort sit before anyone books a workshop. The experts still have the final word, but they spend their time checking findings instead of producing them.
This is the first article in our series on where AI adoption gets stuck. Our Process mapping for agentic AI: a step-by-step guide sets out all nine steps; this article goes deep on one of them.
Manual process mapping spends the time your experts do not have #
The usual way to understand business processes is to ask the people who run them. Analysts hold workshops, interview staff, sit beside them for a day, and draw the result as a flowchart. It works, but every hour of it comes from the experts, and in most companies those are the people operations can least release. We described that constraint in Lesson 1: Your experts' time is the ultimate AI bottleneck.
The data-driven alternative has its own limit. Process mining, the best-known form of automated business process discovery, rebuilds a process from the event logs that systems such as an ERP record for every step (van der Aalst). An inbox keeps no such log. Each email is free text, so the process discovery tools that mine ERP data have nothing to read.
That gap matters because so much office work runs through email. In 2012, the McKinsey Global Institute estimated that interaction workers spent about 28% of their working week managing it (MGI, The social economy).
Your inbox already records how the process runs #
Every email still carries the facts an event log would hold, in its subject lines and body: what was asked, when, who answered, and how long the answer took. The task is to turn natural language into something countable, and email data analysis with language models does that.
How the analysis works #
We used sentence embeddings, a technique that turns each email into a list of numbers so that emails about similar things sit close together. In this project the model was S-BERT (Reimers and Gurevych, 2019). A clustering algorithm, K-means, then grouped the emails into request types. For each type, we counted the emails and measured reply time and thread length, two data points we used as a proxy for effort.
The last check was against the client's own systems. Their property-management software exposes 154 API endpoints, the connection points other software uses to read or change data. For each request type, we checked whether software could read the data a reply needs, and whether it could also carry out the action the homeowner asked for.
The result is a list of hypotheses. A cluster labeled "late fees" may mix two different requests, and only a team member who answers them can say so. That review comes next, and it takes hours instead of weeks. The same analysis works wherever requests arrive as text, from accounts payable to sales teams answering inbound inquiries.
A property manager's 25 request types, sorted by volume and feasibility #
Before the project, staff read each homeowner email, looked up the account in the property-management system, and wrote every reply by hand. The analysis covered 5,483 emails from the shared mailbox. They fell into 25 request types, and the 10 largest types carried about 75% of all the mail.
The check against the client's systems then sorted the 25 types by how much of the work software could take on.
| Feasibility through the existing system | Request types | Emails | Share of volume |
|---|---|---|---|
| Fully feasible | 10 | 2,372 | 43% |
| Partially feasible (a person takes the final action) | 12 | 2,364 | 43% |
| Not feasible | 2 | 712 | 13% |
| Clustering artifact (no real request type) | 1 | 35 | 1% |
Volume and feasibility together chose the pilot: three request types, 1,761 emails, about 32% of the total. Late-fee and payment questions make up about 20%, payment authorizations and statements about 6%, and dues questions about 6%. This is AI use case identification the client can check: each choice traces back to a count and a system test.
The AI agent that drafts replies for these three types is now in build. Before the build started, we agreed with the client on the targets it will be judged against: at least 70% of drafts used as written or with light edits, at least 90% accuracy in recognizing the request type, and no reply sent without staff approval. Staff approve, edit or reject each draft on a review screen, which is where users interact with the agent. Operations work rarely has a measure as clear as the conversion rate or click-through rate a marketing team tracks, and these numbers give the pilot one. Those are targets, and we will report the results when the pilot has run.
The client's team told us the report showed them more about their own inbox than years of handling it had.
Experts review the findings instead of producing them #
In this approach, the experts' role changes. They no longer describe the inbox from memory. They work through the report: renaming clusters, merging what the model split, separating what it merged, and flagging the pain points a count misses.
“Instead of going through the inquiries one type at a time, we asked them for the emails and put AI to work. Within days we had more clarity on how they operate than they had built up over years.” Bart Gonczarek, Co-founder and Chief Transformation Officer, Vstorm
A second client shows why the difference matters. Its CEO would not release staff during the year-end sales peak, so a series of workshops was out of the question. We offered the same analysis for less than 10 hours of his team's time, most of it spent exporting data and reviewing findings. He agreed, and the project is under way.
“We told him we did not need his people. We needed his data.” Bart Gonczarek
Customer email is personal data, so the analysis stays contained #
A mailbox export is a transfer of personal data. Under the GDPR, the company handing it over needs a data processing agreement with whoever analyzes it (Article 28), and it should export only what the purpose requires, the principle of data minimization in Article 5(1)(c) (GDPR on EUR-Lex). In practice, that means one mailbox and one period.
Some clients go further and ask their security consultants to review us before any data moves. We answer those questionnaires in writing, before the export.
The choice of model matters as well. Sending a mailbox to cloud-hosted AI tools sends personal data to a third party. Embedding models of the kind used in this analysis are small enough to run on servers we or the client control, and the language models used in later steps can be hosted the same way. We describe one such setup, an air-gapped model benchmarked for a client in the Middle East, in The future of Small Language Models in the middle-market.
Where data-led discovery is the wrong tool #
We build custom agentic systems, so we lean toward starting from data. The method still has clear limits.
The work has to leave a written trail. A process run by phone, at a counter or in meetings gives a clustering algorithm nothing to read, and interviews remain the way in.
Volume matters too. When a mailbox receives a few dozen emails a month, one person can read them all in an afternoon, and a model adds little.
Counting also shows frequency, which is a different thing from value, so the largest cluster is not automatically the right quick win. At the property manager, legal, hardship and collections emails are few, yet they carry the most risk, legally and for customer satisfaction, so the pilot sends them straight to staff by design.
Finally, the data has to be allowed to move, or the models have to be allowed to come to it. If neither is possible, the analysis cannot run.
In those cases, a facilitated session with the people who run the process is the better start. Our Pragmatics of AI workshop ranks candidate use cases with your team in one session.
How we run AI process discovery #
At Vstorm, AI-powered discovery from data is part of the Strategize stage of TriStorm, our delivery method. We sign the data agreement, export the records, cluster them and measure effort, check each request type against the client's systems, review the findings with the experts in one session, and choose the first workflow with one success metric. The engineers who run the analysis are the engineers who later build the agent, so the reasons behind the choice carry into the build and, over the long term, into any rerun of the analysis after go-live (agentic AI consulting).
Before you book the first workshop, ask which system already records the work.
Next in this series #
The second article follows a workflow that was chosen this way and then met systems that were not ready for it. It will appear on the Vstorm blog, and we will link it here. To be notified when it is online, subscribe to the Vstorm AI newsletter.
