We built our Customer Intelligence Platform to turn scattered client knowledge into answers our team could find without relying on memory. Here’s what it does, how it’s put together, and the design choices we’d make again.
The problem: client knowledge scattered across Zoom, Slack, and people’s memories
At Data-Sleek, what we knew about our clients was piling up everywhere at once: Zoom meeting recordings, Slack conversations, internal PDFs and knowledge-base docs, our own blogs and case studies, client websites, LinkedIn activity, job postings, funding and firmographic data, industry news, and technical communities like Reddit. Each source held something useful on its own. None of it was connected to any of the others.
In practice, that meant the person who happened to be on the call three weeks ago was the only person who remembered what was said on it. Questions like “What did this client tell us about their biggest blocker?” or “Has this competitor made any executive moves recently?” didn’t have an answer you could look up. They had an answer you had to remember or dig up across recordings, chat history, and spreadsheets, if you thought to look.
The cost showed up in the most expensive way possible: every client case study took multiple days of manual digging to assemble, because there was no single place to look for what a client had actually said, done or asked for.
We’d already chipped away at pieces of this. Our Zoom Meeting Router fixed the naming and folder chaos, so recordings landed in the right place instead of ending up in a pile of “Zoom Meeting (3)” files. Our marketing automation gave every piece of content a predictable home and a machine-readable record. But neither tool answered the bigger question beneath them: once your data is organized, how do you actually ask it something?
What is a customer intelligence platform? Meet Data-Sleek CIP
A customer intelligence platform collects customer data from every touchpoint, unifies it, and turns it into insights a team can act on. Most products in the category serve customer experience and marketing analytics teams. CIP (Customer Intelligence Platform) is ours, built for a B2B services firm. It continuously ingests data about client accounts, competitors, and tool vendors from every channel the business touches, enriches that raw data with AI, and stores the results in a single shared intelligence store. A retrieval-augmented generation (RAG) chat application sits on top, so anyone on the team can ask a natural-language question across it all and get a cited answer back, not a guess.
CIP is built as three connected layers:
- Ingestion. Thirteen purpose-built n8n workflows (CIP-001 through CIP-013), each dedicated to a single source, pull data on a schedule or on demand and land it in AWS S3.
- Intelligence store. SingleStore holds the unified document corpus: semantic passage-level chunks, extracted entities, taxonomy tags and vector embeddings, all in one place.
- RAG chat application. A React chat interface, backed by an Express/TypeScript API, rewrites the question, retrieves evidence through several parallel search strategies, and generates a grounded, cited answer.
Most of those thirteen workflows route their content through CIP-100, a shared processor that runs AI extraction (summaries, entities, action items, and strategic signals) before writing the results to the intelligence store. Zoom and Slack have dedicated processors because they need their own chunking rules. And for anything too long or unstructured to hand to a model as a single block, like a two-hour Zoom transcript or a sprawling web page, a semantic chunking layer called Zparse first breaks it into coherent passages. It preserves the original shape of the conversation or document rather than slicing at arbitrary character counts.
Local LLM for ingestion, your choice of model for chat: why we split the AI work
This is the part we think other teams building similar systems will find useful.
CIP deliberately uses different models for different jobs because ingestion and chat have almost opposite volume and quality profiles.
Ingestion uses two components: Ollama with Mistral-Nemo, self-hosted on our hardware, for extraction, and OpenAI’s text-embedding-3-small model for creating embeddings. Every transcript, web page, job posting, and news article that comes through the pipeline needs to be summarized, classified, and have its entities extracted, continuously and in the background, at a volume that scales with the number of sources and clients we’re tracking, not with how often someone asks a question. Running the extraction locally means there is no per-call cost, no matter how much raw data comes in.
Chat runs through LiteLLM, a model gateway that sits between CIP and whichever provider actually answers the question. The retrieval pipeline still uses a fast model to rewrite the user’s query, identify which accounts, people, and tools it refers to, and rerank the retrieved evidence. But the model that generates the final answer is a choice, not a default: anyone using the chat window can pick the model they want responding (Claude, GPT, or a model we run ourselves) instead of every conversation running through the same one. This is low-volume work by comparison, since it only runs when someone actually asks a question, but it’s the part a person reads directly. That’s exactly where paying for a stronger model earns its keep. A wrong or ungrounded answer costs trust in a way a slightly imperfect background extraction never does.
Put simply: the local model, with no per-call cost, does the high-volume grunt work of turning noise into structured data around the clock. Whatever model the user chooses is reserved for the one moment a human is actually in the loop.
Self-hosted AI infrastructure: SingleStore as both database and vector store
If you’ve read our other posts, you know we’re skeptical of the assumption that everything has to live in someone else’s cloud. CIP follows the same instinct, just applied at a bigger scale.
Ollama runs on Data-Sleek’s own hardware in our homelab, hosting local models such as Mistral-Nemo and Qwen 3.6. That’s specifically to avoid per-call ingestion costs regardless of volume. SingleStore is self-hosted too, and it does double duty as both the relational database and the vector store, which is exactly why we picked it over stitching together something like Postgres for structured data and Pinecone for embeddings. One engine means one place to query, one system to keep online, and no sync job quietly falling behind between two databases that are supposed to agree.
The raw payloads still land in AWS S3, because that’s the right tool for durable, cheap object storage, and there’s no reason to be dogmatic about it. The pattern isn’t “everything on-prem.” It’s “self-hosted where it saves real money at real volume, cloud where it’s genuinely the better tool.” For CIP, that line falls between the AI processing and the raw file drop.
What a RAG chat over client data changes for the team
- For the team: ask one question in one chat window and get an answer synthesized from Zoom calls, Slack, client websites, news, LinkedIn, and internal know-how, with citations back to the source. Case studies that used to take days now come together in the time it takes to ask a few questions.
- For account management: high-severity risks, opportunities, competitor moves, and client blockers detected during AI processing automatically generate alerts, rather than waiting for someone to notice them.
- For search quality: passage-level retrieval means a two-hour client meeting can be matched on one specific sub-topic, rather than being returned as an undifferentiated wall of transcript.
- For trust: every answer is checked against what was actually retrieved. The system is designed to cite only what it has retrieved, and it explicitly states when nothing relevant has been ingested yet, rather than answering from general knowledge.
- For oversight: an admin panel provides daily, per-client visibility into which ingestion workflows actually produced data, so a broken pipeline is visible immediately rather than discovered weeks later when someone asks a question and gets nothing back.
The bigger pattern: small, single-purpose pieces built on clean inputs
CIP-001, the workflow that ingests Zoom meeting transcripts into CIP, pulls from the same recordings that our Zoom Meeting Router now automatically files in the correct client folder. That’s not a coincidence. It’s the same philosophy, one layer further along: find where a small operational habit is quietly corrupting your data, fix it with a tightly scoped tool, and then build the next thing on top of clean inputs.
CIP itself follows that same logic internally. It isn’t one monolithic platform: it’s thirteen small, single-purpose ingestion workflows, a shared processor (plus dedicated ones for Zoom and Slack), and a chat layer, each doing one job well and handing off cleanly to the next. The same discipline that made the Zoom Router and our marketing automation cheap to build and easy to trust is what makes a thirteen-source intelligence platform tractable instead of an unmaintainable mess.
The economics keep holding up, too: local models for the high-volume background work, the user’s chosen model via LiteLLM for the low-volume moment when a person is actually reading the output, self-hosted infrastructure where it saves real money, and cloud where it’s the better tool. None of it is exotic. It’s the same small-pieces, right-sized-cost approach, just pointed at a bigger problem.
Want to see CIP in action?
We’re putting together a short walkthrough of CIP in action, from a raw Zoom transcript landing in S3 to a cited answer in the chat app. Next in this series: what it took to make CIP fast, and why the fix wasn’t a bigger model.
If your team has the same problem we did (valuable client knowledge scattered across tools and living mostly in people’s memories), we’d love to talk. Data-Sleek’s AI consulting team builds practical AI systems for companies that already have data and just want it to be queryable.
Get Cited Answers From Your Data
We build RAG systems like CIP on the calls, chats, and documents you already have. Bring one question your team can’t answer today, and we’ll show you how.
Tools mentioned in this post
- n8n, workflow automation (ingestion workflows CIP-001 to CIP-013)
- Ollama, runs open models on your own hardware
- Mistral AI, Mistral NeMo announcement
- OpenAI, Embeddings guide (text-embedding-3-small)
- LiteLLM documentation, model gateway
- SingleStore documentation, vector functions
FAQ: building a customer intelligence platform with RAG
What is a customer intelligence platform?
A customer intelligence platform collects customer data from every touchpoint (meeting recordings, chat, documents, websites, news, and public data), unifies it and turns it into insights a team can act on. Ours, CIP, also covers competitors and tool vendors and adds a RAG chat on top, so anyone on the team can ask a question in plain English and get an answer with citations back to the original sources.
How does a RAG chatbot give cited answers instead of guesses?
Retrieval-augmented generation (RAG) first searches your own data for the passages most relevant to the question, then asks the model to answer only from those passages and to cite them. CIP rewrites the question, retrieves evidence with several search strategies in parallel, reranks it, and says so explicitly when nothing relevant has been ingested yet, instead of answering from general knowledge.
Why use a local LLM for ingestion and a different model for chat?
The two jobs have opposite profiles. Ingestion runs around the clock and its volume grows with every source and client, so a self-hosted model such as Mistral-Nemo on Ollama avoids a per-call cost on every document. Chat runs only when someone asks a question and a person reads the result, so that’s where paying for a stronger model, such as Claude or GPT through a gateway like LiteLLM, is worth it.
Can SingleStore be used as a vector database for RAG?
Yes. SingleStore stores vector embeddings and runs vector similarity search alongside regular SQL tables, so one engine can hold the documents, extracted entities, tags, and embeddings. That avoids running a separate relational database and vector store and keeping them in sync.
What data sources can an AI knowledge base about clients ingest?
Anything the business already touches. CIP ingests Zoom recordings, Slack conversations, internal PDFs and knowledge-base documents, our own blogs and case studies, client websites, LinkedIn activity, job postings, funding and firmographic data, industry news, and technical communities like Reddit, through thirteen n8n workflows, one per source.
