Fewer how-to tickets by putting help where the question starts

A ticket is a symptom of a flow nobody explained

Rota is a sales ERP for field sellers at a regional parts distributor. Dani, a seller three weeks into the job, is building her first multi-line quote. She hits a discount that asks for approval, and she does not know why. She can open a manual in another tab, ask a colleague, or file a ticket. Most people file the ticket.

That is the problem the case starts from. The support queue was full of “how do I” questions, and each one was a flow that could not explain itself on the screen where the question began.

What I did, and what I did not

I mapped every flow against the real screen, found where the documentation and the product disagreed, and wrote the knowledge base the assistant answers from.

• I mapped the flows

  About fifty flows in five modules, each checked on the screen against its documentation, using seven different user profiles.

• I found where docs and product disagreed

  Around fifteen mismatches per module. Some became interface fixes, some became questions for the business, and some became defects for the product team.

• I set the method and wrote the content

  One source feeding three outputs: a manual, a tour and the text the assistant reads. I wrote a dozen guides and rewrote the assistant's files for a seller, in plain words.

• I audited the help against the tickets

  A review of past tickets to see which questions the help should answer first.

A few flows carry most of the questions

Mapping the flows against the screen showed two things. First, the documentation had drifted: what it said and what the product did were different in roughly fifteen places per module. A help system built on that would have repeated the errors with more confidence.

Second, the questions were not spread evenly. Reading the tickets by flow, a handful of flows gathered most of them, and most of those were “how do I” rather than “this is broken”.

flows hold 48% of the tickets

3 of ~50

of those tickets are “how do I” questions

60%

To find that, I read through several thousand past tickets and grouped them by the flow they came from. The coverage map in the prototype shows the same spread, one cell per flow.

Three decisions, each with a cost

• Cover the three flows that cause the tickets, not all fifty

  Covering everything is slow, and most of it would sit unused. Covering the few flows that carry the volume gives the largest drop for the least content to keep true. The rest wait.

• Teach the assistant to say “I don't know”

  An assistant that always answers will sometimes invent a rule. The knowledge base I wrote marks critical data as “check on the screen” and gives the assistant room to decline, name its source and hand the question to a person. A wrong answer about a price costs more than a refusal.

• Put the help inside the screen

  A manual in another tab asks the seller to leave the task and come back. Help placed where the question starts, as a hint, a tour or a question to the assistant, keeps the seller in the flow.

One thing stays open: who keeps the content true when a screen changes. I come back to it in the reflection.

One source, three outputs

1. Map the flow on the real screen→
2. Write one source→
3. Manual→
4. Tour→
5. Text for the assistant

Each flow is written once, after it is checked on the screen, and the three outputs are cut from that one source. When the screen changes, one text changes and the three follow.

The prototype, piece by piece

• The funnel

  Move how much of the volume the help covers and how well the assistant resolves it, and watch the tickets change. The arithmetic stays on screen so the headline is never a number to take on trust.

• Rumo, the assistant

  It answers from a guide and names it, so the seller can check. When no guide covers the question, it says it cannot answer and does not guess. Either way there is a way to hand the question to a person, with the context attached.

• The quote screen, without and with help

  The same screen twice. Without help, a discount over the limit says only “Approval required”. With help, it says why and what to do, and a four-step tour walks through the first quote.

• The coverage map

  Every flow as one cell, shaded by its share of tickets, with the three covered ones marked. It shows why a few flows came first.

The funnel, with the arithmetic

The headline is a product of three numbers, shown rather than asserted.

fewer tickets inside the covered flows

0.60 × 0.70 = 42%

fewer tickets overall

0.48 × 0.42 ≈ 20%

How much rests on one assumption

Almost all of the headline rests on one number: how many of the “how do I” questions the assistant resolves. The coverage and the share of how-to tickets come from reading the tickets. The resolution rate is the part nobody has measured, so the slider in the prototype lets you move it.

0.48 × 0.60 × 0.50 ≈ 14% fewer tickets overall

50% resolved

0.48 × 0.60 × 0.70 ≈ 20% fewer tickets overall

70% resolved

0.48 × 0.60 × 0.90 ≈ 26% fewer tickets overall

90% resolved

What I would call a pass

Before trusting any of this I would set the bar first: with five or more new sellers on a real first quote, at least four finish it without asking a person, and the assistant declines, instead of guessing, on every question the guides do not cover. If fewer finish, the content is the problem, not the idea.

What went wrong, and what is still open

The first version of the help was worse than I thought it was.

• Internal words leaked into the guides

  The first guides and assistant files carried phrases from my own testing, such as “in the test” and “I did not see the option”, and quoted test prices as if they were rules.

• No “I don't know” where it mattered

  The assistant's files had no “check on the screen” on critical data, so nothing told it to stop short of a guess.

• A sentence from the spec contradicted the screen

  A line taken from the specification said a reservation is released, and the screen showed otherwise. It had to go.

• My first test was too small to prove anything

  I tried the assistant on a single real question and it came back “Partial”. One question cannot show whether a knowledge base holds.

That is why decision two exists, and why I rewrote the guides and the assistant's files for a seller, without jargon.

What I would do next

Everything I have is weak evidence: it points somewhere, it does not prove it. The next step is to test with five or more sellers, with real tasks, before trusting any of the figures above. The open question I would raise with the team is the one from the strategy: when a screen changes, who updates the source?