Introduction
Every time a customer contacts support to ask a question that's already been answered before, something has quietly failed. Not the agent, the system.
Repetitive tickets are a symptom of a documentation gap. Customers can't find answers on their own, so they reach out. Agents answer the same questions dozens of times a week, pulling time and energy away from complex issues that actually need human attention. The cycle repeats, the queue grows, and everyone loses.
My solution was to build a Knowledge Base system that worked hard enough that customers could resolve issues before they ever needed to raise a ticket and agents could close the ones that did come in faster than ever before.
The Problem
Without structured, accessible documentation, support teams operate in a constant state of reactive chaos. The specific gaps I was working to close were:
No centralized source of truth: agents were giving inconsistent answers depending on who picked up the ticket
High volume of repetitive inquiries: common questions were consuming disproportionate agent bandwidth
No self-service capability: customers had no way to find answers independently, making the support team the only point of resolution for every issue, big or small
Inconsistent onboarding experience: new customers had no structured guide to refer to, leading to confusion and unnecessary early-stage tickets
What I Built
Working inside HubSpot, I developed a two-layer Knowledge Base system: one layer facing customers, one facing the internal team. each designed for a distinct purpose.
Layer 1: Customer-Facing Onboarding Article: A structured Getting Started Guide built specifically for new customers. It covered timelines, expectations, frequently asked questions, and guidance on how and when to reach support. The goal was to give customers enough clarity in the first 48 hours that the most common onboarding questions answered themselves.
Layer 2: Internal SOP for Support Agents: A parallel KB version built exclusively for the support team. This version went deeper, including escalation pathways, tone guidance, follow-up protocols, and response frameworks. Agents no longer had to rely on institutional memory or ask senior colleagues for routine decisions. The answer was already documented.
Validation: HubSpot AI Customer Agent Testing: This is the step that separated this project from a standard documentation exercise. Before publishing, I stress-tested every article using HubSpot's AI Customer Agent. Feeding it real sample customer queries to evaluate three things: whether the AI could surface the right article, whether the response it generated was accurate, and whether the tone landed correctly for a customer in a moment of frustration or confusion.
Articles that failed the test were revised until they passed. Only validated articles made it into the live Knowledge Base.
Portal Integration: The final KB was structured specifically for customer portal deployment meaning customers could self-serve directly from their dashboard without needing to navigate elsewhere or open a support ticket.
What This Demonstrates
Documentation is often treated as an afterthought in support operations. Something that gets done when there's time, which means it rarely gets done properly. This project treated documentation as infrastructure: something that needs to be deliberately designed, rigorously tested, and built to serve two different audiences simultaneously.
The AI validation layer in particular reflects a mindset I bring to every project. Don't assume something works because it looks right. Test it against reality, find where it breaks, and fix it before it reaches the customer.
Good documentation doesn't just answer questions. It scales the knowledge of your best agent across the entire team and then beyond the team to the customer themselves.