Support
Escalation is easy. Escalating without losing the conversation is the hard part.
Every assistant escalates. The difference between one that helps a team and one that annoys it is entirely in what the person on the other side receives.
- Private launchOnboarding selected teams now
- Built by CreoglyphSeven client engagements behind the product
The handoff that recreates the work
The common implementation escalates by presenting a contact form. The visitor, who has already explained their situation once, is asked to explain it again into a textarea. Roughly half do not.
The half who do produce a message that arrives with no context. Support does not know what the assistant tried, which pages it read, or what it said before giving up. The first reply is therefore a discovery question, which the visitor has now answered twice.
The net effect is an assistant that added a step. It intercepted a question, failed, and handed over less information than a plain contact form would have collected.
What changes
Today
- Visitor asks something the assistant cannot answer
- Assistant apologises and shows a contact form
- Visitor retypes the question, or leaves
- Support receives a bare message with no history
- First reply is a question the visitor already answered
With an assistant
- Assistant recognises it cannot answer and says so plainly
- Escalation fires on a written rule, not a guess
- The full transcript travels with it, including what was retrieved
- Support sees the question, the attempted answer and the pages read
- The failed question is logged as a content gap
Rules you can audit, not judgement made fresh each time
Explicit request
The visitor asks for a person. This one is not negotiable and should never be argued with, deflected, or answered with another suggestion.
Repeated failure
Two consecutive refusals, or two answers followed by a rephrasing of the same question. Rephrasing is the clearest signal that an answer missed.
Marked topic
Topics you have decided are always human: cancellations, complaints, anything legal, anything involving money already paid. Marked in configuration, not inferred.
Low confidence with high stakes
A weakly supported answer on a pricing or contractual question should escalate rather than ship. The same confidence level on a definitional question should not.
What a good handoff payload actually contains
Six things. Anything less and the person receiving it starts from zero.
The full conversation, verbatim
Including the assistant's failed attempts. The failures are the most informative part, because they show what the visitor kept asking in different words.
The retrieval trail
Which pages were searched and which passages came back. Without it you know the assistant failed but not why, which makes the transcript useless for fixing the underlying content.
The trigger that fired
An escalation on explicit request belongs in a different queue from one on repeated failure, and treating them identically wastes the distinction.
The page, and time spent on it
A pricing question after four minutes on the pricing page is a different conversation from the same question ten seconds after landing on the homepage.
Any contact detail already given
So nobody is asked for it twice.
Whether a content fix would have prevented it
That field is what turns a support log into a product input, and almost nothing ships with it.
Where the data goes
Transcripts are stored so they can be handed over and reviewed. Live handoff with a person waiting is planned for launch on the Scale plan, and is written as planned everywhere on this site because it is not built. Security and data boundaries.
Questions
Signal
Is this your situation?
Access is by waitlist, demo request or public-content pilot. Describe the question your visitors keep asking and we will tell you honestly whether it fits.