Support tickets and pre sale questions are different signals

A website assistant on a marketing site collects two very different kinds of conversation, and most teams analyse them as one pile. The result is an average that describes neither group.

Pre sale questions come from people deciding whether to buy. Post sale questions come from people who already did. They differ in what they reveal, who should act on them, and what a good outcome looks like.

What each one tells you

A pre sale question is a marketing signal. It says the site did not communicate something a buyer needed. The owner is whoever owns the website. Success means the question stops appearing because the page now answers it.

A post sale question is a product or documentation signal. It says the product was unclear or the docs were incomplete. The owner is product or support. Success means the question stops appearing because the product got clearer, or it gets answered faster because the docs improved.

Both are useful. Averaging them hides both.

How to tell them apart without asking

You usually can, from context that is already available:

• Page location. Pricing, features and comparison pages skew pre sale. Docs, help and account pages skew post sale.
• Phrasing. “Can I” and “do you” are usually pre sale. “How do I” and “why is” are usually post sale.
• Specificity. Pre sale questions are about capability in general. Post sale questions reference a specific thing the person is looking at.
• Session context. A visitor who arrived from search and asked one question is likely evaluating. A returning visitor deep in a workflow is not.

None of these is perfect on its own. Together they sort most conversations correctly, and the ambiguous remainder is small enough to read by hand.

The routing consequence

Once separated, the two streams should go to different places. Pre sale questions belong in the content roadmap. Post sale questions belong in the documentation backlog and, when they repeat enough, in the product roadmap.

Sending everything to support is the default failure. It buries marketing signal under operational load, and the people best placed to fix a pricing page never see the evidence that it needs fixing.

The metric that changes

For pre sale, the useful metric is the rate at which a question category disappears after you publish the answer. For post sale, it is time to resolution and whether the same issue recurs.

Deflection rate, the number people usually reach for, is a post sale metric wearing a marketing badge. On a pre sale conversation, deflecting a question is not obviously a win. Sometimes the right outcome is a person, because the question signals a serious buyer with a specific concern.

A caution about mixing them in a dashboard

If your analytics view shows one number for questions answered, you will optimise for the wrong thing. A pre sale question answered by a page edit and a post sale question resolved by a support reply are both successes, but they are not the same success and they do not trade off against each other.

Split the view. Two smaller honest numbers beat one large misleading one.

Why conflating them corrupts both queues

They arrive through the same widget and look similar in a log, and almost everything about how they should be handled differs.

A pre sale question is time sensitive in minutes. The person is deciding now, and an answer tomorrow is worthless. A support ticket from an existing customer is time sensitive in hours and the relationship survives a wait.

The right responder differs. A pre sale question needs someone who can talk about fit and occasionally about price. A support ticket needs someone with access to the account.

The right metric differs. Pre sale is measured on conversion, support on resolution. Mixing them into one queue with one response target guarantees one of them is served badly, usually the pre sale one, because tickets have a process and questions do not.

Telling them apart automatically

The page is the strongest signal and it is free. Pricing, comparison and product pages skew pre sale. Documentation, account and help pages skew support.

Phrasing is next. Present tense about a problem, my something is not working, is support. Conditional phrasing about capability, does it do, can it handle, is pre sale.

Whether the visitor references an account is close to definitive.

None of these is reliable alone and together they are good enough to route, particularly since the cost of a wrong route is a forwarded message rather than a lost customer.

What each queue needs from the assistant

For pre sale, the assistant should answer from marketing and documentation together, capture contact details after helping, and escalate on buying intent it cannot satisfy.

For support, it should answer from documentation only, refuse anything account specific immediately rather than attempting it, and escalate with the full transcript.

The configurations are different enough that some teams run two agents. That is reasonable where volume justifies it, and unnecessary below a few hundred conversations a month, where one agent with good escalation rules covers both.

Routing when you genuinely cannot tell

A share of questions are ambiguous, and forcing a guess is worse than handling ambiguity deliberately.

The safe default is the pre sale queue, because the cost of a misroute is asymmetric. A pre sale question sitting in a support queue for a day is a lost deal. A support question in the pre sale queue is forwarded in a minute.

One clarifying question is acceptable where it is genuinely useful and phrased as help rather than as triage. Asking whether someone already has an account is a normal thing to ask and resolves most ambiguity in one exchange.

What does not work is asking the visitor to choose a category before saying anything. It puts your internal structure in front of their question, and it is the reason so many people close the widget on the first screen.

One widget, two behaviours

The routing decision should change what the assistant does, not present the visitor with a choice. Internal structure is not the visitor's problem.

Two agents or one

Below a few hundred conversations a month, one agent with good escalation rules handles both and the operational simplicity is worth more than the precision.

Above that, two agents start to pay, because the configurations genuinely diverge. The pre sale agent indexes marketing and documentation and captures contact details. The support agent indexes documentation only and refuses anything account specific immediately.

The split also lets you measure them separately, which matters because they are judged on different outcomes. Averaging conversion and resolution into one number tells you nothing about either.

What makes the split work is placement rather than detection. Put the pre sale agent on marketing templates and the support agent on documentation and account templates, and most routing happens correctly without any classification at all.