How We Architect a Customer Intelligence Platform

The shape of the system

A customer intelligence platform is, underneath, a pipeline. Messages come in from lots of places, get cleaned up and understood, get grouped into themes, and come out as summaries, trends, and alerts your teams can act on.

It is easiest to picture as six steps. The system pulls messages in. It puts them all into one common shape. It reads and tags each one. It makes them searchable by meaning. It groups them into themes and writes summaries. And it shows the results in dashboards, alerts, and reports. The rest of this article walks through each step and the choices that matter inside it.

Getting messages out of a dozen tools

This first step is the least exciting and the most important. Your customer messages live in separate tools, and each one shares its data in its own way.

We connect to the usual ones: help desks like Zendesk and Freshdesk, email inboxes, the WhatsApp Business API, Instagram and Facebook comments, review sites like Google, Trustpilot, and G2, app store reviews, and community or social channels. Some of these can push a message to us the moment it arrives. Others we check on a schedule and pull in.

The hard part here is not clever, it is reliability. These connections break, change without warning, and hit usage limits, so each one has to be built to retry, recover, and be watched. There is also history to handle. A new client usually wants the last year of messages analysed on day one, which means pulling in hundreds of thousands of old messages without creating duplicates. We always save the original message first, untouched, so nothing is ever lost.

Putting everything in one shape

A review, a support ticket, and a tweet look nothing alike. Before we can analyse them together, we put them all into one simple format: who said it, on which channel, when, the text itself, the language, and any extra detail the source gives us, like a star rating or an order number.

Two small jobs here matter a lot later. We remove duplicates, because the same message often comes in twice. And we link a message to the customer behind it where we can, so later you can weigh feedback by who said it, not just how often it was said. This is also the natural place to protect personal data, by masking sensitive details before anything moves further down the line.

Turning text into useful labels

Now each message gets read and labelled. First the basic checks: what language is it, is it spam, is it even about you. Then the labels that matter: the topic, the type, whether it is a question, a complaint, a request, or praise, and the mood behind it.

This is where the first real decision comes in, and it is about cost. You could send every single message to a top model like GPT-4o or Claude and get excellent labels. But at a few million messages a month, that gets expensive very fast. So we split the work. For the huge volume of everyday labelling, we use a smaller, cheaper model, often an open one like Llama 3, which is more than good enough for this job. We save the powerful, pricey models for the step where their quality really shows, which is writing the theme summaries. Knowing where to spend and where to save is one of the biggest things that keeps the running cost sensible, and it is a choice an off the shelf tool rarely gives you.

Finding meaning, and where it is stored

To group messages by what they mean, each one is turned into an embedding. That is simply a list of numbers that captures the meaning of the message, so two messages that say the same thing in different words end up close together.

Those numbers need to live somewhere that can search them quickly. For most clients we start with pgvector, which adds that ability to the ordinary database we are already running. It is cheap, simple, and handles millions of messages without trouble. We only move to a specialised tool like Pinecone when the volume gets very large. Starting simple and upgrading only when needed saves clients money they are often asked to spend far too early.

Grouping messages into themes

Once every message is stored this way, themes appear naturally by grouping the ones that sit close together. We do two things at once. We let new themes surface on their own, so we catch issues nobody thought to look for. And we keep tracking the themes you already care about, so your key categories stay steady over time.

Two things take real care. New themes need clear names, so a model reads a few examples from each group and writes a short, human label. And themes shift over time as language and problems change, so we review and tidy them on a schedule instead of letting them go stale. Getting this balance right, steady enough to trust but flexible enough to spot the new, is most of the skill.

Summaries, trends, and alerts

This is where the powerful models earn their keep, because now they run once per theme instead of once per message. For each theme, a top model like Claude or GPT-4o writes a plain summary, picks out the specific requests inside it, and pulls a few real customer quotes.

At the same time, the system watches each theme against its normal level and flags anything rising sharply. It can also keep an eye out for specific things you care about, like a jump in refund complaints or an angry message from a major account, and ping the right person straight away instead of waiting for someone to check a dashboard.

Why we run most of it on a schedule, and some of it instantly

Most of this runs as scheduled jobs, every hour or overnight. That is far cheaper, and it is fine for trends and reports, which do not change by the minute. But some things should not wait. So for urgent cases, a new message gets a quick check the moment it arrives and can set off an alert in seconds, while the heavier analysis stays on its schedule. Running it this way keeps cost low without losing speed where speed matters.

Where it runs, and how it scales

For clients who want to keep tight control of their data, and most do, we set the whole thing up inside their own cloud account, on AWS, Azure, or GCP, so customer data never leaves their environment. The pieces involved are fairly standard, and none of it is exotic.

Scale is usually less scary than people expect. Millions of messages a month are handled comfortably, because the work splits up easily. If there is more to process, you add more capacity. The cost does not really grow with the number of messages. It grows with how much of the expensive model work you choose to do, which is exactly why the earlier choices about where to spend matter so much.

A realistic cost picture

Every project is different, but the shape is consistent. A working pilot, connecting two or three channels and setting up the pipeline with a dashboard, usually lands between eight and twenty lakh rupees over four to eight weeks. A wider rollout, with many channels and custom dashboards, costs more.

For running cost, picture a business with about five lakh messages a month. Turning all of them into those meaning numbers costs very little, often a few thousand rupees. Labelling them with a smaller model is mostly the cost of a modest server, very roughly fifty thousand to one lakh rupees a month, and less on shared setups. The summaries from the powerful models, which run per theme rather than per message, usually add somewhere between fifty thousand and two lakh rupees a month. The honest takeaway is simple. The running cost is mostly about how much model work you do, and good design keeps that in check.

What we get right that in-house projects miss

Teams often build a promising demo in a few weeks, then get stuck. The demo reads a few thousand messages and looks great. The hard parts are the ones a demo never shows: keeping a dozen connections running reliably, checking the themes are actually correct and not just believable, keeping cost under control as volume grows, and handling personal data properly. Those are the parts we have built and run before, and they are the difference between a clever prototype and something a business can lean on every day.