NOTE: Demo visuals include blurred data or synthetic placeholders to protect customer privacy.
Where Questions Slow Down
Customers already have ways to get answers, but the fastest path often becomes a ticket. Andy noted that Abnormal receives thousands of support tickets per month, and about 20% could be answered directly from customer-facing Salesforce documentation. Yet customers still raise tickets because searching through many docs is a chore, and response times range from hours to 24 hours, even for “easy” questions.
A few friction points showed up clearly in the current workflow:
- **Search is high-effort: **customers do not want to hunt through long, scattered support articles.
- The existing web bot is too thin: the public-facing bot may lack technical depth when it has access to only limited content.
- Ticketing adds delay by default: even straightforward questions inherit queue time and handoffs.
Rebuild Retrieval for Support
This iteration transforms the experience into a customer-facing Question Bot, indexed against support articles rather than just public marketing pages. Andy framed it as a step beyond replying on Slack or following up after meetings: the bot should help customers get answers directly, with citations and links to the underlying sources.
As Andy put it, “I spent a couple of weeks kind of building this bot that answers questions in our Slack channel… and then follow[s] up… [and] automatically detect[s] that question, and then follow up, for the rep.” From there, the natural next step is to bring the same verified workflow closer to the customer.
Key capabilities in this phase:
- Topic-based chunking to preserve meaning, rather than embedding entire articles as one block.
- Keyword-aware retrieval (BM25-style matching) to handle cybersecurity jargon and product terms customers actually use.
- AI-generated related keywords to improve recall when customers describe issues differently from the docs.
- Re-ranking (cross-encoder or LLM-based) to promote the most relevant passages before answering.
- Cited responses behind login so customers can verify sources, while limiting competitor access to support content.
Operationally, Andy also demonstrated a pragmatic footprint: the prototype runs in a Vercel function written in Python, and he noted it can operate without standing up a dedicated vector database. The early result he highlighted was efficiency: on average, it can find what it needs with about one search tool call across Salesforce articles before generating a final answer.
Faster Answers, Less Ticketing
This shift creates value for two groups at once: customers and internal teams. Customers get a shorter path to a reliable answer with sources. Support and GTM get fewer repetitive tickets and fewer “let me get back to you” follow-ups during live conversations.
What improves with this approach:
- Customers: faster self-serve resolution for common, doc-answerable questions, with direct links to the underlying article.
- Support: fewer low-complexity tickets entering the queue, reducing load and helping focus on harder cases.
- GTM: fewer meeting follow-ups when questions can be answered immediately and confidently, with citations.
Next step: tighten the customer-facing UI and expand evaluation on real ticket categories, so the bot can confidently deflect the most common doc-backed questions while escalating edge cases to Support.
Early Signals of Self-Serve Trust
Peers recognize the practical tradeoff Andy is making: accuracy beats flash. The bot earns trust by grounding answers in the same customer-facing sources customers can read, and by making those sources visible in every response.
This also nudges Abnormal’s culture in a useful direction. Instead of treating Q&A as a human queue, teams start treating it as a product surface: measurable retrieval quality, clear citations, and a feedback loop that reduces repeated work over time.
