Three months ago we started with a single question: what do energy company customers actually ask? The answer was in 22,912 support tickets. We analyzed them, found 40 thematic clusters, and auto-generated FAQ answers.
But ticket analysis was never the end goal. It was the foundation.
The logical next step
Once you have a knowledge base built on thousands of real customer interactions, the logical thing to do is put that knowledge base to work. Not as a report someone reads — but as an engine that delivers answers.
The insights from the analysis didn't just tell us what customers ask. They told us how they ask it, through which channels, with what expectations. That information is exactly what you need to build a platform that works across multiple channels.
Three channels, one knowledge base
The platform we're building has three channels:
Ticket handling. Incoming tickets are automatically categorized based on the clusters we identified in the analysis. The agent retrieves relevant FAQ answers and customer context, then generates a response suggestion. High-confidence answers go out directly. Low-confidence ones go to a reviewer.
This isn't "a chatbot on email." This is a system that knows the full knowledge base, understands which cluster a question falls into, and generates the answer based on proven patterns from thousands of previous interactions.
Voice. Phone calls are the channel where context is needed most. A customer who calls has usually already emailed or searched the website. The voice channel gives the agent real-time context before the customer has even finished speaking. What interactions has this customer had before? Which cluster does the question probably fall into? What's the most likely answer?
The human — the phone agent — stays central. But instead of searching through systems themselves, they get the right information served at the right moment.
Chat. A customer-facing assistant that knows the full knowledge base and learns from every interaction. Not a generic chatbot sitting on the website — an assistant specifically trained on the questions these customers ask, in the language they use, about the topics that are relevant to them.
And when the chat assistant detects a question falls outside its scope? It hands off smoothly to a human agent, with full context from the conversation up to that point.
Why one platform
The critical insight isn't that we're building three channels. It's that the three channels share the same knowledge base.
A phone conversation about outages improves the chat response about outages. An email question about tariff changes enriches the knowledge base the voice channel uses. Every customer interaction, through every channel, makes the system smarter.
This only works if the channels aren't siloed but integrated. The same context layer. The same retrieval pipeline. The same feedback loop. One platform, not three tools.
The bigger picture
What we're building for this energy company isn't unique to the energy sector. The patterns — thousands of customer interactions, multiple channels, the need for proactive rather than reactive customer contact — exist everywhere.
But the energy sector is an interesting place to start. Because the questions are predictable (tariffs, billing, contracts, outages), because the volume is high, and because the impact is directly measurable.
Fewer tickets that need manual answers. Faster responses via chat. Better-informed phone agents. Fewer customers calling with a question that should have been on the website already.
What proactive customer contact means
The ultimate vision goes beyond responding. A platform that knows enough about customer behavior can predict which questions are coming — based on seasons, tariff changes, outages, or annual settlements.
That means: informing customers before they reach out. A notification about a tariff change prevents hundreds of tickets. A proactive message about an outage prevents dozens of phone calls.
From reactive to proactive. From customer contact as a cost center to customer contact as an opportunity. That's where the data points. And that's what we're building.