Building a HubSpot support agent that reduced support time by 80%

When you are building early-stage products, customer support is one of the best sources of learning. It tells you where the product is confusing, where operations are brittle, and where customers need reassurance. But in smaller teams, it can also become a constraint. In some scenarios, the same person learning from the support queue is often the person responsible for product strategy, delivery, partner management and the next venture in the portfolio. This was the situation I found myself in as the product lead in the IAGL ventures team.

I was working in a lean ventures team that had two live products in market: an eSIM proposition and a travel insurance product. One of my core responsibilities alongside my product role was customer support, and this component had grown to the point it was taking up to 20 hours a week of my time. It soon became clear to me that I needed to explore some options to get some capacity back via agentic support systems. This is the story of how I built a HubSpot support agent to handle repeatable customer queries, reduce my support workload by around 80%, and free up time for higher-leverage product work.

My venture team was made up of 10 individuals, all of whom were specialised and operating across multiple ventures.

The first product in our portfolio was an eSIM benefit. This created a specific type of support demand: customers often tried to activate their eSIM shortly before travelling, which meant issues tended to appear at moments of high urgency. If the link did not work, or if a customer could not find their benefit, they needed help quickly.

The other product was travel insurance, which brought a different set of constraints. Travel insurance sits in a regulated environment, so customer support had to be handled carefully. An agentic system could help with operational questions, but it could not give insurance advice, interpret cover, recommend products, or answer questions taht should be handled through approved policy documentation or escalation to a human.

The challenge here was not simply: can we use AI to answer customer questions? But instead, which customer questions are safe, repeatable, data-backed, and valuable enough to delegate to an agent?

A large share of our support queue followed a familiar pattern. Customers were asking about early eSIM activation, eSIM link issues, Avios awards, voucher codes, benefit information, or small account changes such as updating an email address. Most of these queries were not strategically difficult. They required me to identify the customer, check information in HubSpot, retrieve the right benefit or status field, and respond in a consistent way.

The early eSIM activation use case is a good example of why the process needed nuance. We had decided not to activate eSIMs by default before the cooling-off period ended, because that could create a risk of customers taking the benefit and then cancelling the policy. But when customers requested early access, we could review and grant it on a case-by-case basis.

That type of support flow was well suited to an agent: common enough to justify automation, bounded enough to control, and dependent on data already available in the CRM.

I did not want to create a generic chatbot. I wanted a constrained support agent with a specific job:

This distinction here matters. In my opinion, a good support agent is not just a language model with access to company data. It is an operating process with boundaries. For this agent, the boundaries were especially important. It could answer operational questions about benefits, eSIM activation, Avios information, and customer account details. It could not answer questions about insurance products, policy interpretation, purchasing decisions, complaints, or anything that looked like regulated advice.

That gave us a simple rule: the agent should reduce manual support effort, not take on judgement it was not qualified to make.

I built the support agent using HubSpot’s agent builder and connected it to the information it needed to resolve the highest-volume queries.

The key CRM properties included:

I also connected the agent to our FAQs and gave it access to previous support threads. This helped in two ways.

First, it gave the agent a source of truth for common answers. Second, it helped the agent mirror the support style we already wanted customers to experience. I used examples from my own previous responses as best-practice exemplars, so the agent was not only told what to say, but shown what good looks like.

The response guidance covered:

In practice, a lot of agent design is deciding what the agent should not do. The more regulated or sensitive the environment, the more important this becomes.

The agent was tested in stages. Firstly, I used test users in HubSpot. This allowed me to check whether the agent could retrieve the right information, recognise common query types, and respond in the expected format without touching real customers.

Then I tested it with the internal team working on the product. This helped validate the operational logic: were the answers correct, did the agent understand edge cases, and were the escalation rules clear enough?

Finally, I tested with a small number of colleagues who had bought policies themselves. That gave us a more realistic view of how the agent handled genuine customer phrasing, incomplete information, and questions that did not perfectly match our expected categories.

The key point is that testing was not only about whether the agent could answer correctly. It was also about whether the agent knew when not to answer, which was just as important for our use case.

We firstly released the agent to Wanda Plus customers, our most premium customer group, who had the highest volume of applicable queries. This gave us a controlled environment to observe real interactions, review quality, and improve the agent before making it available more broadly.

Once we had more confidence, we expanded access to all Wanda users. The agent became available through the customer portal and also handled email queries, which represented the majority of support traffic.

This approach gave us a practical feedback loop:

For agent launches, that loop is more useful than trying to perfect the system before it meets a real customer.

After launch, quality assurance became an ongoing part of running the agent. I reviewed conversations to understand where the agent was performing well and where it needed refinement. Good responses became examples to reinforce. Weak responses became input for better guidance, stricter guardrails, or clearer escalation rules.

The QA process focused on five questions:

That last point is easy to underestimate. The quality of an agent is not only measured by the number of queries it resolves. It is also measured by the quality of the queries it refuses or escalates.

The agent reduced the time I spent on customer support by around 80%, and importantly changed the operating rhythm of the team. Customers could get faster answers to common operational questions, particularly where the answer depended on information already stored in HubSpot. At the same time, I was able to spend less of my week manually handling repetitive tickets and more of it on product strategy and execution, including work on the next venture in the portfolio.

The agent did not remove the need for me within the support function. It removed the need for a me to repeatedly perform the same data lookup and response workflow when the query was already known, safe, and well understood.

The biggest lesson was that useful agents are built around workflow clarity, not just model capability.

The agent worked because it had:

In other words, the technology mattered, but the operating system around the technology mattered more. For teams thinking about building agents, I would start with this question: what repetitive decision or support flow already has a known answer, a trusted data source, and a clear escalation point? I would say this is the best place to begin