There is a specific way a chat goes quietly wrong. The visitor asks something reasonable, the agent does not know, the agent says they will check, and then the chat moves on to something else and ends warmly. Everyone involved feels fine. The visitor is left waiting for an answer that nobody is still tracking, and the agent has genuinely forgotten, because at the time it was one line in the middle of four conversations.
The knowledge gaps card exists for that moment. It is on the right rail of the agent console, it watches the agent's own outgoing messages rather than the visitor's, and it pins every admission of not knowing to a list alongside the question that prompted it.
What counts as not knowing
Each agent message is stripped of HTML, normalised, and split into sentences. Anything under six characters is dropped. What remains is tested against twenty patterns in four categories, and the order the categories are tested in is part of the design.
- Escalate comes first — you saying you need to consult someone. Let me check with my manager, I will run this by engineering, I need to loop in the billing team. Two patterns cover it, and they run before everything else so that checking with a person is not swallowed by the broader rule about checking in general.
- Uncertain is next, eight patterns. I am not sure, I do not know the exact figure, I am not familiar with that, and the whole family of good question, let me check. Running these before the lookup rules is what makes that last one read as uncertainty rather than as a plain lookup.
- Lookup is the broadest, also eight patterns. Let me check, let me look that up, one moment while I verify, I will have to confirm, bear with me while I find out.
- Promise-followup is the vaguest, two patterns: I will get back to you, I will circle back, I will let you know once. No concrete deliverable attached.
One match in any category is enough. A sentence that matches nothing is ignored entirely.
The thirteen things that look like it and are not
False positives kill a card like this faster than anything, because an agent who sees one wrong row stops reading the rest. So thirteen rejection rules run after the match and throw candidates out.
The one that earns its place immediately is let me know. It begins the same way as let me check and means the exact opposite: you are asking the visitor to follow up, not promising to. Without that rule the list would fill with rows for a phrase agents type twenty times a shift.
The others are the same shape. I will wait and I will be right back are not gaps. I am sure you will find is confidence about the visitor. I do not think you need is an opinion. No need to check cancels itself. I will have to ask you is you asking them, not you consulting a colleague. Let me think is deliberation rather than a lookup, and the code says so explicitly, on the grounds that a false row is more annoying than a missed one. Let me get you the link is an offer.
And one is a jurisdiction rule: I will check back with you is a follow-up commitment and belongs to a different card, so this one declines it.
The question attached to each row
A row that only said let me check would be almost useless a day later. So every visitor message updates a running buffer holding their most recent question, preferring a question-shaped sentence and falling back to the last substantial one. When an agent message produces a gap, that buffer is copied onto the row.
The result reads as a pair. The visitor asking how the SAML trial works, and underneath it the agent saying they will check. Trimmed to a hundred and sixty characters for the question and two hundred and twenty for the reply.
The buffer is deliberately not cleared when the agent replies. If you say you will check, then a moment later say you will check on the second part too, both rows attach to the same original question, which is almost always what you meant.
Nothing resolves itself
There is no automatic resolution on this card. Not a timer, not an inference from a later message, nothing. A row opens and stays open until a person clicks Resolved, Skip, or Reopen.
That is unusual among the console overlays and the reasoning is stated in the source: a stale green tick on a real let me check is expensive. The visitor walks away believing an answer is coming. Better to leave a row open and slightly annoying than to close it on a guess.
Resolving optionally captures a one-line note of the answer you eventually gave, which is the part worth doing. It is the difference between a list of things nobody knew and a list of things nobody knew alongside what turned out to be true.
Skip is for genuine mis-extraction and is not the same as resolving. Keeping them apart is what stops the card's own accuracy from being hidden by ordinary use.
Why it holds up your wrap-up
The card patches itself into the wrap-up panel in two places. Any open gap flips the readiness indicator to warn, so a chat with an unanswered lookup does not present itself as ready to close. That single behaviour is most of the value: the failure mode this card was built for is the agent forgetting, and the wrap-up is the last moment before forgetting becomes permanent.
Resolved gaps do not hold up readiness but do appear in the recap that the Copy and Save buttons produce, with their answer notes attached. A handover therefore carries both what was asked and what was found.
State is per visitor and in memory. A transfer or an accept drops it, so the next agent starts clean instead of inheriting rows they cannot resolve.
The export nobody asks for and everybody wants
The per-chat use is the smaller half. The footer carries a button that produces a markdown digest of gaps across every conversation, resolved ones included by default.
What that produces is a list of the questions your team could not answer on the spot, in customers' own words, with whatever answer was eventually found underneath. That is the single best input to a help centre backlog, and it is normally reconstructed by hand from transcript reading, which is why it is normally not reconstructed at all.
The workflow is a weekly paste into a doc or ticket. Repeats rise to the top on their own. A question that appears four times in a week is an article, and the answer note is most of its first draft. Writing articles that actually deflect covers the shape of the article itself; this list is where the topic comes from.
It is also the correct input to your AI assistant's source material. An answer your agents had to look up is by definition an answer that is not in the material the assistant reads, and keeping AI chat answers current is largely a matter of feeding it exactly this list.
What to measure
- Distinct topics appearing on the digest more than twice in a month. Each is an article that does not exist yet.
- The share of rows resolved with an answer note rather than a bare tick, which tells you whether the loop is closing.
- Skip rate, which is the card's own false-positive rate. A rising skip rate means the patterns need looking at, not that agents are careless.
- Chats ending with an open gap. That is the broken-promise count, and it should trend to nearly zero once the wrap-up warning is being respected.
Put it into practice
- Open a live chat and press Ctrl+Shift+Y, or click the pill, to expand the card.
- Send yourself the phrase let me know if that works, and confirm no row appears. That is the negation list doing its job.
- Send let me check with my manager and watch it file under escalate rather than lookup.
- Resolve one row with an answer note and one with a bare tick, then read the wrap-up recap and see which is more useful a week later.
- Export the digest every Friday and paste it somewhere the people who write documentation will read it.
- Treat a chat that will not go green because of an open gap as the system working, not as an obstacle.
Knowledge gaps tell you what your agents could not answer. For the coarser question of what the conversation was about at all, the topic badge your console puts on a chat covers the nine-subject classifier and the confidence label that comes with it.