Multi-Intent Detection: How One Transcript Containing Four Different Process Views Becomes Four Coherent Diagrams

Multi-intent detection is what saves a consultant interviewing a small-and-mid-sized business roughly two hours per engagement. Any stakeholder write-up contains the current state, the pain points, the wishlist and the proposed future state all tangled together, sorting them by hand is where the time goes. The classifier does the sort in one pass.

A typical stakeholder interview transcript for a process-mapping engagement does not describe a single process. It describes four, interleaved throughout the conversation in ways that are obvious to human readers but invisible to naive parsing. The four perspectives are: the as-is process (how things actually work today), the to-be process (how they should work or are being redesigned to work), pain points (specific problems with the as-is that motivated the conversation), and wishlist items (ideas the stakeholder would like to see, not necessarily tied to a specific process redesign).

A sample sentence from a real interview: 'So today the invoice comes in, finance opens it manually, checks it against the PO, which takes forever, and we really need to get to a place where the AI reads it automatically, but honestly I think we should also just get rid of the PO check altogether.' That one sentence contains as-is ('finance opens it manually, checks against PO'), a pain point ('which takes forever'), a to-be ('AI reads it automatically'), and a wishlist item ('get rid of the PO check'). A classifier that treats all of this as one process produces a diagram that is structurally incoherent: tasks that contradict each other, gateways that make no sense, pain-point mentions sitting in the sequence flow as if they were steps.

The multi-intent classifier uses four intent types, chosen because they are the minimal set that captures the perspectives that actually appear in real documents without overlapping enough to make classification ambiguous.

• as_is: the current process as it operates today. Signal words: 'currently', 'today', 'we do', 'the way it works', 'right now'. This is the intent the diagram should reflect unless the user explicitly opts into mapping a different one.
• to_be: a target or proposed future state. Signal words: 'we want to', 'should be', 'in the future', 'the goal is', 'we're redesigning'. This intent deserves its own diagram alongside the as-is rather than being merged into it.
• pain_point: specific problems with the as-is that are driving the desire for change. Signal words: 'the problem is', 'we hate', 'it is frustrating', 'always breaks', 'takes too long'. These are kept out of the sequence flow and stored as optimization hints on the session for later reference (or, if you pick 'All detected processes' at the disambiguation step, become their own standalone diagram).
• wishlist: aspirational features or changes that the stakeholder would like to see, not necessarily tied to a specific redesign. Signal words: 'it would be nice if', 'I wish', 'eventually', 'dreaming about'. Same handling as pain_point: stored as optimization hints on the session, not injected into the sequence flow of the selected diagram.

The classifier assigns each detected intent a confidence score between 0 and 1. When more than one intent has confidence above 0.7, the flow surfaces this to the user via a clarifying question rather than silently picking one. The threshold of 0.7 is empirically chosen: below it, the disambiguation dialogs appear too frequently on documents that are genuinely single-intent; above it, real multi-intent documents get silently collapsed. The confidence threshold (0.7) is stable and has not changed since the feature shipped.

When disambiguation triggers, the user sees a question whose options are built from each detected intent's process label and summary: there is no fixed three-option menu. If the model detects a current-state and a target-state, the options read something like 'Invoice processing (as-is)' and 'Invoice processing (to-be)' plus an 'All detected processes' choice that generates every intent as its own diagram. The user picks one or several; the diagrams are then generated sequentially, not rendered in a single side-by-side canvas.

The common mental model of multi-intent detection is 'oh, it disambiguates between current and future processes'. That framing undersells what the feature does. The bigger value is preventing the corruption that happens when pain points and wishlist items end up in the diagram as if they were process steps. A diagram that has 'customer is frustrated by long wait' as a task in the Customer swimlane is worse than having no diagram at all, it looks authoritative but represents nothing that actually happens.

The separation also enables downstream analyses that would otherwise be impossible. The as-is diagram becomes the baseline for cost and heatmap analysis today. A to-be diagram becomes a natural comparison target. Pain points and wishlist items are captured as separate optimization hints on the session, available as context for later work. A deeper feedback loop, where pain points automatically prioritise ESSII recommendations and wishlist items inform the to-be design: is described in the v2 transformation plan and is designed but not yet implemented. Even without that integration, keeping the four intents separate is what lets each downstream view stay interpretable; fused intents produce a single artefact that cannot serve any of the roles well.

Multi-intent is a diagnostic feeder for the AI transformation plan. The as-is diagram anchors the current-state analysis, the pain points feed directly into the ESSII recommendations, and the wishlist items surface as candidates for the target state. For a consultant advising an SMB, having the four perspectives cleanly separated is what makes the plan that follows coherent rather than a smoothie of everything the stakeholder said on the call.