DEV Community: Emil

Knowledge Base For AI Agents: What It Must Do

Emil — Tue, 15 Sep 2026 20:00:33 +0000

A knowledge base built for people and a knowledge base built for AI agents look similar from the outside and behave very differently in use. People navigate: they remember roughly where something lives, open the page and read around the part they need. An agent does none of that. It issues a query, receives some passages, and answers from whatever came back. Everything that makes the human experience tolerable — browsing, skimming, asking a colleague which page is the current one — is unavailable to it. This is a practical checklist of what a knowledge base has to provide before connecting an agent to it produces answers you would let a customer see.

Agent Access Is Retrieval, Not Search

A search box returns a ranked list and lets a human decide which result is relevant. That last step is doing enormous work, and it disappears when an agent is the reader. The agent takes the passages it receives as the truth of the matter, so anything ranked third that should have been first becomes a wrong answer rather than a slightly inconvenient click.

This shifts where quality has to live. For humans, a good knowledge base needs decent titles and a search that surfaces plausible candidates. For agents, it needs retrieval that is right on the first attempt, because there is no second attempt and no judgement applied to what comes back.

The implication for evaluation is direct: judge a tool by the answers it produces to your real questions, not by how its search results page looks. A demo that returns five relevant-looking documents tells you very little. A demo that answers 'what is our refund window for annual plans' correctly, with the source attached, tells you everything.

Five Requirements Worth Checking First

First, live retrieval rather than a copy. If the integration works by exporting documents into another tool, the export is stale from the moment it finishes and someone owns the job of refreshing it. Second, citations on every answer, naming the document the content came from, so a wrong answer can be traced to either bad retrieval or a bad source.

Third, a clean failure mode. The knowledge base must be able to say it does not know. An agent that improvises when retrieval returns nothing is worse than no agent, because the failure is invisible in the output. Fourth, permissions that follow the person asking, not a single service account with access to everything — otherwise the first sensitive document anyone adds turns the whole thing into a leak waiting to happen.

Fifth, a standard connection interface. The Model Context Protocol exists precisely so the knowledge base can expose one read interface that any compatible assistant uses, instead of a bespoke integration per tool that gets rebuilt every time the team changes assistants. These five are not a feature wish list; each one maps to a specific way the arrangement fails without it.

Freshness Matters More Once Agents Read It

Stale documentation has always been a problem, but the failure was self-limiting. A human reading a page from two years ago usually notices: the screenshots look wrong, the named owner left, the tone of the process no longer matches how things are done. Suspicion kicks in and they go ask someone.

An agent has no such instinct. It will quote a superseded policy with exactly the same confidence as a current one, and the answer it produces reads perfectly. The cost of staleness therefore rises sharply the moment agents start reading, which is worth knowing before rather than after.

The mitigation is cheap if it is built in: show when a document was last updated and who owns it, surface that alongside the answer, and treat unanswered questions as a backlog rather than an error. A lookup that returns nothing is a timestamped signal that a specific gap exists and someone needed it filled — the most useful prompt for writing a missing page you will ever get.

How To Evaluate A Tool In One Afternoon

Collect twenty questions your team has actually asked in the last month. Take them from chat history rather than inventing them; real questions are messier and more specific than the ones you would write, which is the point. Load three to five documents that should contain the answers.

Run all twenty and score each answer three ways: correct, cited to the right document, and honest when the answer is not present. Deliberately include four or five questions whose answers you have not documented — the handling of those tells you more than the handling of the ones you have.

A tool that answers fifteen of twenty correctly with citations, and declines the other five cleanly, is working. A tool that answers all twenty, including the five with no source, has told you the most important thing about itself in under an hour. This test costs an afternoon and settles a decision that otherwise takes weeks of demos.

Frequently asked questions

What makes a knowledge base suitable for AI agents?

Live retrieval instead of stale exports, citations on every answer, an honest response when nothing is found, permissions that follow the person asking, and a standard read interface such as MCP so any assistant can connect without a custom build.

Do we need a separate knowledge base for agents?

No. The same documents should serve both, because two sources diverge immediately. What changes is the retrieval layer on top: agents need the right passage returned first, where people can browse and recover from an imperfect result themselves.

How many documents before this is worth doing?

Three to five covering your most repeated questions are enough to test the idea. Coverage matters far less than hit rate, and writing comprehensively up front usually produces volume without improving the answers people actually receive.

What happens when the answer is not documented?

The knowledge base should say so plainly rather than improvise. A clean not-found is useful: it records that a specific question was asked and went unanswered, which is the best possible prompt for writing the page that was missing.

Is It Safe To Connect AI To Internal Docs?

Emil — Mon, 14 Sep 2026 19:00:57 +0000

The question comes up in every team that considers it, usually phrased as a single worry about security. It is actually three separate questions wearing one coat: who can see which documents, what the assistant is able to do besides read, and what the vendor does with the content that passes through. They have different answers and very different risk profiles, and conflating them is why the decision often stalls for months on a concern that turns out to be the smallest of the three.

Separate Three Questions People Conflate

The first question is access: can this arrangement show someone a document they were not supposed to see. That is a real risk and the one worth most of your attention, because it is the failure that cannot be undone once it happens.

The second is capability: what can the assistant change. An agent that can only read has a bounded worst case. An agent that can act — modify records, send messages, trigger workflows — has a worst case that extends to everything within its reach, and deserves a completely different level of scrutiny.

The third is vendor handling: where the content goes, whether it is retained, and whether it trains anyone's model. This is the question people lead with and it is usually the most tractable, because it is answered by reading a contract rather than by designing a system.

Read-Only Bounds The Worst Case

Restricting an assistant to reading is the single most effective control available, and it is worth treating as a permanent design decision rather than a cautious first phase. The worst thing a read-only assistant can do is show someone information — a serious failure if the permissions are wrong, but a failure that does not corrupt records, send anything to a customer, or require a restore from backup.

Write access changes the shape of the risk entirely. A misread instruction becomes a modified record, and the blast radius follows whatever the integration was granted. The benefit that justifies that exposure is usually much smaller than it sounds in the proposal.

It also makes the internal conversation easier. Granting an assistant read access to documentation a colleague could already open is a modest decision that a security review can approve quickly. Bundling it with the ability to act turns a modest decision into a large one, and the modest version is where nearly all the value sits anyway.

Permissions Follow The Person, Not The Bot

The most common design mistake is giving the assistant its own account with access to everything, then relying on it to be tactful about what it reveals. That is not a permission model; it is a hope. Anyone who can ask a question can, with enough rephrasing, reach anything that account can read.

The correct model is that a request inherits the permissions of the person making it. If a document is restricted to the leadership group, an engineer asking a question that would be answered by that document gets the same result as if they had searched manually: nothing. The assistant becomes a faster path to what someone already had, never a route around the rules.

This also means the existing access structure is the thing that gets tested. If your documentation is currently a single shared space where sensitive material happens to be filed among ordinary pages, that was already a problem — connecting an assistant just makes it visible faster, which is an argument for fixing it rather than for postponing the project.

Retention, Training And What To Ask Vendors

Four questions settle most of this, and all four should have written answers. Is content used to train any model, by the knowledge base vendor or the model provider behind it. How long are queries and retrieved passages retained, and in what form. Where is the data processed, which matters for teams with residency obligations. And what does the audit trail record — who asked what, and which documents were returned.

The audit question is the one most often forgotten and the most useful in practice. A log of questions and the documents used to answer them is what lets you investigate an incident at all, and it doubles as the clearest signal of which documentation people actually depend on.

Be specific about the model provider as well as the knowledge base vendor, since the content passes through both. A vendor that cannot answer plainly in writing has answered the question anyway.

A Rollout That Does Not Need A Committee

Start with documentation that is already company-wide: onboarding material, published processes, product information, support policies. There is no access question to resolve for content everyone can already read, which removes the hardest part of the decision from the first phase entirely.

Run that for a few weeks with a small group and look at the logs. You will learn which questions people actually bring, how often the answer was present, and whether the citations hold up — all of it evidence you can take into the conversation about extending scope, in place of speculation.

Then add restricted material deliberately, one group at a time, with the permission model tested before anything sensitive is loaded. Staged this way, the project never requires one large approval covering every risk at once, which is usually what stalls it.

Frequently asked questions

Is it safe to connect an AI assistant to internal docs?

It can be, if access follows the person asking rather than a shared service account, the assistant is read-only, and the vendor states in writing that content is not used for training. Those three conditions cover most of the risk.

Why does read-only access matter so much?

It bounds the worst case to showing someone information rather than changing something. A misread instruction with write access becomes a modified record or a sent message, with a blast radius matching whatever the integration was granted.

Will our documents be used to train a model?

That depends entirely on the vendor and the model provider behind it, so ask both and require the answer in writing. It is a contractual question rather than a technical one, and a vague answer is itself informative.

Where should a cautious team start?

With documentation everyone can already read: onboarding material, published processes, support policies. There is no access question to resolve, so the first phase tests answer quality and the permission model before anything sensitive is added.

How To Write Docs An AI Can Answer From

Emil — Sun, 13 Sep 2026 19:00:06 +0000

Connecting an assistant to your documentation exposes how the documentation is written in a way that nothing else does. Pages that a human tolerates — a heading covering four topics, a paragraph whose meaning depends on the one above it, a title naming the team rather than the subject — produce visibly worse answers, because retrieval works on passages and a passage that cannot stand alone is a passage that misleads when quoted. The good news is that the fixes are ordinary editing, and every one of them also makes the page better for the human who arrives mid-document from a search result.

One Page, One Question, One Answer

The single highest-leverage habit is scoping a page to one question a person would actually ask. 'Refund policy' is a subject. 'How do we handle a refund request after the thirty day window' is a question, and a page written to answer it will be retrieved accurately for that question and ignored for others.

The common failure is the omnibus page: a document titled after a department or a system that accumulates every decision anyone made about it. Retrieval on such a page is a coin toss, because the passage that matches your query sits beside four passages about unrelated matters and the surrounding context pulls the answer sideways.

Splitting is usually the whole fix. When a page covers three decisions, three pages covering one decision each retrieve better, read faster and are easier to keep current — an outdated section in an omnibus page tends to survive for years because nobody wants to audit the whole document to change one part.

Write Passages That Survive Being Excerpted

Assume every paragraph will be read alone, with no title above it and nothing after it. That is roughly what happens when a passage is retrieved, and it makes certain habits expensive. Pronouns pointing at the previous section, 'as mentioned above', and continuations that begin with 'this means' all lose their referent the moment the passage is lifted out.

The repair is to name the subject in the sentence rather than relying on the reader having just read something else. 'This is capped at €500' becomes 'Refunds issued without manager approval are capped at €500.' It reads as slightly more repetitive to someone going through the page top to bottom, and far clearer to everyone else, which is most readers.

The same applies to conditions. A rule stated without its scope — 'approval is required' — invites an answer that overgeneralises. Say who it applies to and when, in the same sentence as the rule, and the retrieved passage carries its own boundaries with it.

Title Pages With The Words People Use

Titles carry disproportionate weight in retrieval, and internal documentation is full of titles written from the author's point of view rather than the asker's. 'Billing operations runbook' is how the owner thinks about it; 'what to do when a customer is charged twice' is how it gets searched for.

A reliable technique is to name the page after the question that would send someone looking for it, then use the first sentence to state the answer directly. Anyone landing there gets what they came for immediately, and the retrieval layer gets a strong, unambiguous signal about what the page is for.

Where internal jargon is unavoidable, include the plain-language equivalent once in the opening lines. If the system is called Atlas internally but everyone else says invoicing, the page should contain both words, because half your team will search with each of them and so will the assistant working on their behalf.

Dates, Owners And The Trust Problem

Every page should carry a last-reviewed date and a named owner. This is not bureaucracy: it is the information a reader needs to decide how much weight to put on what they just read, and it is the only practical defence against silent staleness once an assistant is quoting documents confidently.

The named owner also solves the update question. Documentation rots because revising it is a separate task competing with real work, and 'someone should fix this' resolves to nobody. A name attached to a page turns a vague obligation into a specific one, and makes it obvious who to ask when the page and reality disagree.

The cheapest maintenance habit is to update at the moment of use. When someone answers a question in chat that the documentation should have covered, the answer is already written — moving it into the page takes seconds while the context is fresh, and that is a habit rather than a project.

A Fifteen Minute Audit Of What You Have

Take your five most-consulted documents. For each one, read the title and ask whether it is a question someone would search. Then pick three paragraphs at random, read each in isolation, and ask whether it still means what it is supposed to mean with nothing around it.

Most teams find the same three problems: titles naming systems rather than situations, paragraphs whose subject lives two paragraphs earlier, and pages covering several unrelated decisions under one banner. Fixing those on five documents takes an afternoon and improves answer quality more than adding twenty new pages would.

Then let real usage drive the rest. Questions that get asked and return nothing are a precise backlog, generated by demand instead of someone's idea of completeness, and writing along those contours keeps the knowledge base small enough that every page in it stays current.

Frequently asked questions

How should documents be structured for AI retrieval?

One page per question people actually ask, with the answer stated in the first sentence. Omnibus pages covering several unrelated decisions retrieve poorly, because the matching passage arrives surrounded by material about something else entirely.

Why do passages need to make sense alone?

Retrieval lifts paragraphs out of their page. Anything relying on 'as mentioned above', an earlier pronoun, or a condition stated two sections back loses its meaning at exactly the moment an assistant quotes it to someone.

Do we need to rewrite our existing documentation?

No. Audit the five documents people consult most, fix titles that name systems instead of situations, and split pages covering several decisions. That takes an afternoon and improves answers more than writing twenty new pages would.

How do we keep documentation from going stale?

Put a last-reviewed date and a named owner on every page, and update at the moment of use — when someone answers in chat what the docs should have covered, move that answer across while the context is still fresh.

Unified Customer View: What It Is And Who Needs One

Emil — Mon, 07 Sep 2026 23:00:20 +0000

A unified customer view is a single place where one customer's history across all your tools can be seen at once: what they paid, what they bought, what they were told and what tasks are open for them. The idea sounds simple, but the terms around it blur together. CRM, CDP, data warehouse and customer 360 all point at the same concept from different angles. This post clarifies what the view actually is, the two ways to build one, and why the choice matters differently at five people than at five hundred.

Two Ways To Build One

There are two fundamentally different ways to assemble a unified customer view, and the difference decides the project size, the running cost and how fresh the answer is. The choice shapes everything that follows, so it is worth making deliberately rather than inheriting it from a vendor pitch.

The first is a stored approach. Customer data is collected from your tools and copied into a central system that holds its own record, which is what customer data platforms and most CRMs do. The record can be shaped, enriched and reused, but it has to be built, kept current and paid for.

The second is a live approach. Each tool stays the source of truth, and a lookup queries them at the moment you ask. Ziikly does this: search an email and the connected tools answer in parallel, with nothing stored and nothing to keep in sync.

Stored Profiles Versus Live Queries

Stored profiles have real strengths. Because the data is copied in, it can be normalized, combined with analytics, and made available to other systems. That is why CDPs and warehouses exist, and why large teams invest in them despite the cost, because the copy is the price of the power.

The costs arrive with the strengths. The copy must be kept in sync, identity matching must be handled, and freshness depends on sync frequency. A profile built from last night's sync can be wrong about today's payment failure, which is exactly when the answer matters.

Live queries keep the tools as the source of truth. The answer is always current because the lookup reads the live system. Nothing to sync, nothing to keep current, and nothing to get stale. No pipeline to monitor, and no pipeline to pay for while you would rather be working.

Cost Difference Between The Approaches

The cost difference is where the two approaches diverge hardest at small team size, and it is usually the deciding factor long before any feature is compared. The gap grows with every seat, every synced record and every maintenance task, which makes it the first question to ask, not the last.

A stored system charges for the infrastructure of holding and syncing data, often as per-seat licenses or per-tracked-user pricing, plus the setup project of mapping sources. For a team of five, that is a real budget line before a single customer is looked up, and it recurs every year.

A live lookup charges for the search capability. Ziikly uses one flat plan regardless of how many customers you look up, and setup is pasting read-only keys. There is no data to migrate and no pipeline to maintain, so the bill stays flat as the usage grows.

Which Suits A Team Under Ten

For a team under ten, the decisive questions are simple. What are you actually going to do with the unified view, and how current does the answer need to be? Two honest answers settle most of the debate, and the rest is preference dressed up as strategy.

If the daily use is support and billing context, seeing what the customer did across the tools, a live lookup covers it completely at a fraction of the cost and effort of a stored system. The daily questions get answered with today's data, not last night's.

If the ambition is building marketing segments or running cross-tool analytics, a stored system earns its price. The catch is that most small teams overbuy that capability years before they need it, and the license bill arrives long before the first segment does, so time the purchase to the plan, not the pitch.

Customer 360 View: The Same Idea

A customer 360 view is the same goal under a different name. Where 'unified customer view' is common among smaller teams, 'customer 360' is the term bigger platforms popularised. Both mean the same thing: one complete picture of a customer across every system.

Whichever word you search for, the practical question is identical — is the picture built from a stored copy that must be synced, or queried live from the tools that hold the truth? A live view answers the same customer 360 question with current data and nothing to maintain.

How A Live Unified View Works

Ziikly builds a unified customer view live. Connect your tools once with read-only keys, then search a customer's email and the connected systems answer in parallel — charges from Stripe, orders from Shopify, invoices from Bokio, enrollment from your course platform, conversations and tasks.

Because the view is assembled at the moment you search, it cannot be stale. There is no sync, no import and no database to maintain, and the picture grows automatically when you connect another tool.

What You See In One View

The view groups everything a connected tool holds for that customer around their email address: payments and receipts, purchases and orders, invoices and balances, course progress, subscriber state, support tickets and open tasks — side by side on one screen, in seconds.

Frequently asked questions

Is A Unified Customer View The Same As A Customer 360?

Yes — they are the same goal under different names. 'Unified customer view' is common among smaller teams; 'customer 360' was popularised by larger platforms. Both mean one complete customer picture across systems. Ziikly builds it live by querying your tools with read-only keys instead of storing a synced copy.

Is This The Same As A CRM?

Not exactly, though they overlap. A CRM stores and manages your customer relationships and records. A unified customer view shows a customer's history across your tools. A CRM can provide that view for what it stores; a live lookup shows the full picture from every connected tool.

Do I need a data warehouse to build a unified customer view?

Only if you want to store and analyze the data. A data warehouse is a stored approach that gives analytics power. A live lookup answers customer questions with current data from your tools, without copying anything into a warehouse. The copy is the difference between the two.

Single Customer View And Why It Breaks So Often

Emil — Mon, 07 Sep 2026 22:00:26 +0000

A single customer view promises one complete record of a customer across every system, and it sounds straightforward until you try to keep one alive. The reality is that these views break constantly, and the breaking points are predictable: identity matching fails when the same person appears under different emails in different tools, synced profiles go stale the moment something changes, and the common key everyone relies on gets typed differently from one system to the next. This post explains where the failures come from and what keeps a single customer view working.

Identity Matching Across Systems

The core challenge of any single customer view is deciding that two records are the same person. That is identity matching, and it is where most views quietly fail. The whole system silently depends on that guess, and a wrong guess quietly corrupts the picture.

Tools rarely share a perfect identifier. The same person buys with one email, subscribes with another and files a support ticket under a third. A stored view has to guess that those three addresses are one customer, and the guess is rarely checked, so a wrong merge quietly becomes the truth.

Every guess is a chance to merge the wrong records or miss the right ones. The failed matches show up as duplicate customers, fragmented histories and, at worst, one customer's private data attached to another's profile. Each failure erodes the trust the view depends on.

Stale Records In A Synced Profile

A stored single customer view is a snapshot, and snapshots age. The record was true at sync time and drifts from reality until the next sync. In between, it presents old news as current fact, which is the quiet failure mode of every synced profile.

A customer's payment fails after the nightly sync, and the stored view still shows a happy paying subscriber. A refund is processed in Stripe, and the synced profile keeps showing the charge until the next batch runs. Neither wrong answer is caught until someone checks the source.

Every stale record quietly undermines the trust the view is meant to create. A live query sidesteps the whole category: search the email and each connected tool answers at that moment, so the record cannot be stale because it is never stored. The trust stays intact because the source never drifts.

Keeping Email As The Common Key

The most practical fix for a breaking single customer view is to keep one identifier consistent across your tools: the email address. It is the key your systems already share, so it needs no new infrastructure, no new field and no new import. The discipline is small and the payoff is large.

Email is the key your tools already share. Payments, orders, conversations and support tickets are all tied to an address in most systems, which means an email search can reliably reconstruct the customer across all of them, without building a separate identity layer, which is the piece that usually breaks.

Email is not a perfect key, and it is worth saying so honestly. Addresses change, get typoed and are shared. But for a small team, the practical match rate is far higher than the alternatives, and Ziikly treats email as the lookup key on purpose.

How Ziikly Keeps A Single View Working

Ziikly treats email as the single key on purpose and skips the stored profile entirely. Connect your tools with read-only keys, search a customer's email, and each connected system answers at that moment — so there is no copy to go stale and no identity layer to keep correct.

The result is a single customer view that cannot drift, because it is rebuilt from the source tools on every search. Nothing is merged into a central record, so a wrong merge can never corrupt the picture.

What A Single View Shows

Search an email and the view brings together what your tools hold for that customer: payments from Stripe, orders from Shopify, invoices from Bokio or Fortnox, course enrollment, subscriber state, tickets, conversations and tasks — one screen, current as of the search.

Frequently asked questions

What Breaks A Match Most Often?

Different emails. A customer who buys under one address and writes support under another defeats naive matching. The most common causes are typos, separate personal and work addresses, and tools that capture the address inconsistently at signup. Capturing it cleanly at every touchpoint fixes most of these.

Can I Build A Single Customer View Without A Database?

Yes. Instead of copying customer data into a stored profile that needs syncing and identity matching, Ziikly queries each connected tool live at search time and joins the results by email. There is no database to build, no sync to maintain and no stale copy to worry about.

Is a single customer view the same as a CRM?

No. A CRM is a tool that stores and manages relationship records. A single customer view is the goal of seeing one customer's full history. A CRM can be part of building one, but the view itself is about the whole picture.

Federated Data Versus A Data Warehouse Approach

Emil — Mon, 07 Sep 2026 22:00:20 +0000

Two philosophies govern how a company works with the data spread across its tools. The data warehouse approach copies everything into one central store where it can be queried, joined and analyzed as a whole. The federated approach leaves the data in each source system and queries them on demand, assembling the answer at the moment it is needed. Each has real strengths and real failure modes, and the terms overlap with the CDP and CRM world more than most buyers expect. This post compares them honestly across freshness, cost and reliability.

Copying Data Into One Store

The warehouse approach starts with a decision: the data leaves the tools and lands in one owned store. Nightly jobs or streaming pipelines pull charges, orders and conversations into a single database. The copy is the whole point of the approach, and everything else is plumbing around it.

Once there, the data is genuinely powerful. You can join across sources, run analytics that were impossible in any single tool, and build reports for the whole company from one place. That is the strength the warehouse sells, and it is real, but the power comes with a bill.

The cost is the machinery around the copy: the extraction, the transformation, the loading, the schema and the reconciliation. Each is a system to run and a place where things break, and each one demands attention from someone, which for a small team means the founder.

Querying Each Source On Demand

The federated approach makes the opposite decision: nothing moves. Each tool stays the source of truth, and a query asks them all at the moment you need an answer. The data stays where it lives, and the answer comes to you, which is the entire architecture in a sentence.

Ziikly works this way. When you search a customer's email, the connected payment, store, inbox and project tools answer in parallel, and the results are assembled on screen. There is no copy to sync and no store to keep fresh. So the setup stays small and the answer stays truthful.

The strength is truthfulness. The answer reflects the tools as they are right now, so a payment that failed this morning shows as failed, not as whatever last night's sync recorded. That freshness is what makes the lookup safe to trust when the stakes are a customer on the phone.

Freshness, Cost And Failure Modes

Comparing the two honestly comes down to three axes: freshness, cost and how they fail. Each axis rewards a different approach, so the honest answer depends on which axis your team actually cares about day to day. Freshness matters to support; joins matter to analytics.

Freshness favors federated data. The answer is always current because there is no copy to be stale. Warehouses are only as fresh as their last sync, and the gap between sync and reality is exactly where the wrong answers come from, quietly and by default.

Cost favors federated data at small scale. There is no pipeline, no storage bill and no maintenance. A warehouse fails by serving stale data, sometimes invisibly; a federated lookup fails loudly, usually as a missing connection, which is easier to notice and fix. The honest synthesis: warehouse where you analyze, federated where you answer.

Frequently asked questions

Which Scales Better Over Time?

Warehouses scale for aggregate analysis and heavy analytics; federated lookup scales for answering individual customer questions with current data. Most small teams scale fine with federated queries and add a warehouse only when real analytics needs arrive. The trigger is the workload, not the headcount.

Is federated data the same as a CDP?

No. A CDP stores collected customer data in its own profiles, which is a warehouse style approach. Federated data stores nothing and queries sources live. Both can describe customer data, but they differ in whether a copy exists and who maintains it.

Do Small Teams Need A CRM? An Honest Answer

Emil — Mon, 07 Sep 2026 21:00:27 +0000

Every small team eventually asks whether it needs a CRM, and the honest answer is "it depends", which is not a cop out. A CRM earns its price when you actively manage relationships and pipeline: chasing deals, tracking follow-ups, keeping notes on every conversation. It is expensive and annoying when your real work is answering questions about customers who already bought, because the record you need already exists in your payment, store and inbox tools. This post gives the honest answer in three parts: when a CRM is clearly worth it, when it is overkill, and what to use before that point.

When The Answer Is Clearly Yes

A small team needs a CRM when the core workflow is outbound: finding prospects, tracking deals and making sure nothing falls through the cracks. That workflow has a rhythm of follow-ups and stages that email alone cannot hold together, and the CRM earns its place there.

If you have a sales pipeline with multiple open deals, stages and owners, a CRM is the working system that keeps it honest. A team running a real sales motion cannot track that reliably in email and spreadsheets for long, because the pipeline moves faster than the notes.

The test is behavioral. If your team constantly loses track of follow-ups, cannot see what stage a deal is in, or loses context between sales calls, the CRM is not a luxury; it is the tool the workflow was missing. Those failures are the signal, not the noise.

When It Is Overkill And Costly

The overkill case is more common than the industry admits: a small team buys a CRM because it is marketed as the place to know your customer, then finds the work is all support and billing, not pipeline. The platform was bought for a job the team was not doing.

For that team, the CRM is a double cost. Per seat licensing adds up as headcount grows, and data entry, the fields, the objects, the record hygiene, becomes a chore nobody owns. Every hour spent maintaining the copy is an hour not spent on the work itself.

Worst of all, the CRM holds a copy of data that already lives elsewhere. The payments are in Stripe, the orders in Shopify, the history in the inbox, and the CRM's version of them is out of date by the time it is typed in.

What To Use Before That Point

Before the pipeline exists, the customer context the team actually needs is already sitting in the tools it uses. The gap is not a missing platform; it is a missing way to see across the tools, and that is a much cheaper problem to solve.

A federated lookup fills that gap. Connect Stripe, Shopify, Missive, Bokio and the rest with read-only keys, search a customer's email, and see their payments, orders and conversations together. No data entry, because the data was entered when the work happened. The record builds itself as the business runs.

The scalable path is to buy the lookup now and the CRM only when the outbound motion actually appears. When it does, the two coexist cleanly: the CRM manages the pipeline while the lookup keeps the customer history truthful, so neither carries the other's job.

Frequently asked questions

At What Headcount Does This Change?

There is no fixed number; the trigger is workflow, not headcount. A five person outbound sales team needs a CRM; a twenty person team that only answers support questions may not. Buy when a sales pipeline becomes an active, daily workflow.

What can I use instead of a CRM for a small team?

A federated customer lookup that reads your existing tools. Search a customer's email and see payments, orders and conversations together, with no data entry. Add a CRM later, only when you need to manage an active pipeline. The lookup covers the daily questions; the CRM covers the pipeline.

Customer Lookup Tool: The Category Explained

Emil — Mon, 07 Sep 2026 21:00:20 +0000

A customer lookup tool is any tool that answers the question "who is this customer?" The category is broad on purpose, because the answer comes in different shapes. Sometimes it is the search box built into a single product, sometimes a dashboard the team built themselves, and sometimes a cross tool product that searches several systems at once. Understanding the category makes the choice clearer: what you need depends on whether your customer's history lives in one tool or across several. This post maps the three shapes honestly and shows where a spreadsheet fits and where it stops.

Built In Search Inside One Product

The most common lookup tool is the one already inside the product. Every payment system, helpdesk and store has a search box that finds a customer's records within that single tool. It answers instantly for the questions that live there, which makes it the baseline every other option is measured against.

That is genuinely useful when the question lives in the tool. Need the Stripe history? Search Stripe. Need the Shopify order? Search Shopify. Each built in search answers its own question perfectly, with no setup and no extra cost, and the friction only starts when the question crosses tools.

The gap appears when the question crosses tools. A customer asking about a charge they paid, an order they placed and an email we sent them needs three different built in searches, and none of them sees the whole picture. That gap is the reason the category exists at all.

Internal Dashboards Teams Build Themselves

The second shape is the dashboard a team builds for itself. When the built in searches stop being enough, someone imports the data into a spreadsheet or a simple database and stitches the customer picture together there, by hand and on their own time, which is the hidden cost of the approach.

This works impressively well for a while. A well kept sheet can answer most customer questions, and it costs nothing but time. As long as the person who maintains it keeps it current, the sheet serves the team faithfully, and the cracks appear only under growth.

The problems are the ones you would expect: the data goes stale, the identity matching breaks, and the person who owns the sheet becomes a dependency. If they are on holiday, the lookup breaks with them, and the team discovers the cost of the shortcut.

Cross Tool Lookup Products

The third shape is a product built for the cross tool question itself. Instead of searching each system, you search once and the connected systems answer in parallel. That single search is the whole point of the category, and the rest of the product exists to make it work.

Ziikly sits here. Connect your payment, store, inbox and project tools with read-only keys, search a customer's email, and the profile shows their charges, orders and conversations together. No data is copied, so there is nothing to keep in sync and nothing to go stale.

The strength is freshness and completeness. The cost is that the product is only as good as the tools you connect, so the lookup covers what you actually use. Connect the tools that matter and the picture stays honest, because it reflects today rather than the last import.

How Ziikly's Customer Lookup Works

Ziikly is built for the cross tool lookup. Connect Stripe, Shopify, Bokio, your course platform, email and support tools once with read-only keys, then type a customer's email into the search bar.

Ziikly queries every connected tool in parallel and joins the results around that email address: payments, orders, invoices, tickets, tasks and conversations side by side. The answer arrives in seconds, and because nothing is stored, it is always current.

What You See In A Lookup

The lookup shows whatever the connected tools hold for that customer: charges and receipts from Stripe, orders from Shopify, invoices and balances from Bokio or Fortnox, enrollment from your course platform, subscriber state from Kit, tickets from Zendesk and tasks from ClickUp.

Searching takes one email address — there is nothing to import, map or maintain. Add a tool later and the same search covers it too.

Frequently asked questions

Can A Spreadsheet Do This Job?

For a while, yes. A well maintained sheet answers most questions, but it goes stale, breaks identity matching and depends on whoever maintains it. A cross tool lookup reads live data from each system, so it stays current with no maintenance.

Which Tools Can Ziikly Search?

Ziikly reads over 30 tools read-only today, from payments (Stripe, PayPal), e-commerce (Shopify, WooCommerce) and accounting (Bokio, Fortnox, Xero) to courses, email, CRM, support, tasks, calendars and forms. Connect the ones you use and a single lookup searches them all.

Does A Customer Lookup Cost Anything?

Ziikly starts free with two non-beta integrations. The paid plan is one flat monthly price for the whole team, so looking up customers costs the same whether it is one person or five — no per-seat fees.

Is a customer lookup tool the same as a CRM?

No. A CRM stores and manages relationship records that you enter or import. A customer lookup tool finds and shows a customer's history. A cross tool lookup like Ziikly shows the history from your existing tools without storing a record.

Customer Data Silos Inside A Five Person Company

Emil — Mon, 07 Sep 2026 20:00:25 +0000

Silos sound like a problem for big enterprises, but a five person company can hold more customer data in silos than a corporation, because every tool is another island. Payments sit in Stripe, orders in Shopify, invoices in Bokio or Fortnox, conversations in Missive, tasks in ClickUp, and nobody has a reason to join them until a question spans two tools. The silos did not appear by decision; they appeared one signup at a time. This post looks at how that happens, the hidden weekly tax they charge, and how to fix them without a migration.

How Silos Appear Without Anyone Deciding

Silos form the way most company problems form, gradually and by default. The team picks a tool for each job: Stripe for payments, Shopify for the store, Bokio for the books, Missive for the inbox, ClickUp for tasks. Each pick was a good decision alone, and none of them asked how the tools relate.

Each choice was sensible alone, and none of them required a decision about how the tools relate. The silos are simply the accumulation of good single tool choices, made at different moments by whoever needed them, which is why nobody recognizes a silo when it forms.

Silos harden with habit. Once the team is used to checking three tools for every customer question, that workflow becomes the normal way of working, and nobody questions it. The cost stops being noticed because it stops being compared, and familiarity becomes the silo's best defense.

The Hidden Weekly Tax They Charge

Silos charge a tax every week, and the tax is invisible because it is paid in small increments. Every customer question becomes a tour of the islands. Nobody bills the tour separately, so nobody sees the total, and the tax survives because it never appears on a report.

Five tool visits per question, a minute or two each, and the context assembled piece by piece in the head of the person answering. Multiply across the week's tickets and the tax is real hours, plus the mistakes that happen when a step is skipped.

The tax also includes the context that is simply lost. A refund decision made without the order record, a support reply written without the payment history, a follow-up that misses the task already assigned. None of those losses ever shows up in a report, yet each one changes the reply the customer gets.

Fixing Silos Without A Migration

The classic fix for silos is a migration: move everything into one system and leave the islands behind. For a five person company, that is usually the wrong answer, expensive, risky and built on the assumption that one tool can replace the others. The assumption is almost always wrong.

The cheaper fix is federation. Leave each tool exactly where it is and add a lookup that reads across them. Ziikly does this with read-only keys, so the store, the payments and the inbox stay put and a customer search returns their history from all of them at once.

No data moves, no workflows are rebuilt, and the silos remain as storage while they disappear as experience. The tools keep doing their jobs, and a lookup joins them only for the questions that cross the boundaries. That is the honest test of a fix: it removes the cost without removing what works.

Frequently asked questions

Do Silos Matter At This Size?

Yes, and they are more common at small size because few teams have tooling to join them. The cost shows up as lookup time, missed context and inconsistent answers. Silos matter exactly when a question spans more than one tool.

What is the cheapest way to break a silo?

Federation. Instead of migrating everything into one system, add a read-only lookup that queries each tool when you search a customer. No data moves, no workflows rebuild, and the customer history appears together while every tool keeps doing its own job.

CDP Vs CRM Vs A Federated Customer View

Emil — Mon, 07 Sep 2026 20:00:19 +0000

CDP, CRM and customer view are three terms that get used as if they mean the same thing, and they do not. A CRM manages the relationships and pipeline you record. A customer data platform collects and unifies customer data for marketing and analytics. A federated customer view answers the daily question "who is this customer?" by querying your existing tools live instead of storing a copy. The honest truth is that the categories overlap, vendors blur the lines, and the right choice depends on what your team actually does with customer data.

What Each Category Was Built To Do

Start with the purpose each category was designed for, because that is what each does best and where each should be judged. A tool is right when its designed job matches the job you actually need done. Everything else is feature creep dressed as advice.

A CRM was built to manage relationships: who you are selling to, where deals stand, what happened in each conversation. It is a working system for sales and account management, and its power is the structured record you maintain. The record is only as good as the daily discipline behind it.

A CDP was built to collect and unify customer data across sources, resolving identities into profiles for marketing, analytics and personalization. Its power is holding and activating the data it collects. That is why it is built for scale rather than for a handful of seats.

Setup Effort Compared Side By Side

Setup effort is where the categories differ most for a small team, because the effort decides whether the tool ever gets used. A system that takes a month to stand up is one the team will quietly abandon, and that failure is worse than never buying it.

A CRM asks for data entry and configuration from the start: fields, pipelines, and the habit of recording every interaction. It can be running in a day but useful only after the records have accumulated. The value follows the data, not the install, so the payoff is always delayed.

A CDP is a project. Sources, events, schemas, identity resolution and destinations all need planning, which is why CDP implementations are measured in weeks and months. It is a data engineering effort sold as a software purchase, and teams discover the scope after the contract.

Annual Cost At Small Team Size

The honest cost comparison at five to ten people is stark, and it is the reason the categories deserve a separate budget decision. Picking the category first, then the vendor, keeps the two decisions honest, and prevents the platform from deciding your architecture for you.

A CDP typically prices per monthly tracked user or through contracts sized to data volume, so the bill scales with your data. For a small team, the annual number often reaches five figures before you have used the platform, and it grows as your data grows.

A CRM prices per seat, so a team of five pays for five licenses forever. A federated customer view uses a flat plan, Ziikly at a single monthly price, regardless of how many customers you search. The cost stays predictable while the usage grows, which is the direction a small team actually wants.

Choosing Without Overbuying

Overbuying is the most common mistake in this category, and it usually happens when a team picks a platform based on what it could do rather than what the team will actually do this quarter. The brochure always wins the shortlist; the usage report tells the truth.

Write the customer data questions your team actually gets asked. If they are mostly "who is this and what happened with them", a federated view covers them and nothing is lost, because those are lookup questions, not platform questions. The list is the cheapest specification you will ever write.

If the questions are "which segment should this campaign target", that is CDP territory. If they are "what is the state of this deal", that is CRM territory. The scalable path is to buy the smallest thing that answers today's questions, and to upgrade only when the questions outgrow the answer.

Frequently asked questions

Can Five People Skip All Three?

Usually yes, if the daily need is customer context. A federated lookup across your existing tools answers most questions a five person team faces. Add a CRM when you need pipeline management, a CDP when you need marketing segmentation. And skip both until a real reason arrives.

What is the difference between a CDP and a federated customer view?

A CDP collects customer data into its own stored profiles and activates it for marketing and analytics. A federated view stores nothing and queries your tools live. The first enables segmentation; the second answers current customer questions. Different jobs, so they rarely compete directly.

The Real Cost Of Switching Tabs Between Tools

Emil — Mon, 07 Sep 2026 19:00:25 +0000

Nobody plans to spend their day switching tabs. It just happens: the customer email is open in Missive, the payment question means a jump to Stripe, the order check means a jump to Shopify, and the account note lives somewhere in ClickUp. Each jump takes a few seconds, but a support day is made of hundreds of them. The real cost is not the seconds; it is the attention that never fully returns after each switch. This post walks through how to count those lookups, what context switching does to your focus, and where the hours actually go.

Counting Lookups In A Normal Week

Start by counting, because the number is usually bigger than anyone expects. Take one support session and track every time an agent leaves the current screen to find an answer in another tool. Count the visits, not the time, and keep a rough tally for the day.

Every refund question is a Stripe visit. Every order question is a Shopify visit. Every invoice question is a Bokio or Fortnox visit. Every past conversation is a Missive visit. A single customer question can easily produce four or five tool visits before the reply is written.

Multiply that by the number of tickets in a week. A team answering forty tickets a day with five lookups each is doing a thousand lookups a week, each one a small journey away from the actual work. The count is also a map of where the context actually lives.

Attention Lost To Context Switching

The seconds are the visible part; the attention cost is the hidden part. When a person switches from writing a reply to scanning a Stripe dashboard and back, their focus does not follow instantly. Research on context switching is consistent: each interruption costs more than the interruption itself.

The toll shows up as the wrong number pasted, the reply that repeats something from the previous ticket, and the question that was already answered two screens ago. These are not carelessness. They are the predictable result of a workflow built on jumps, and they cost more to fix than to prevent.

Reducing the jumps reduces the mistakes that come from them. Ziikly collapses the count rather than moving it around: one email search queries every connected tool in parallel, so the five visits become a single profile on one screen, and the attention stays with the customer.

Where The Hours Actually Go

Across a week the tab switching adds up to real hours, and they do not show up in any report. A lookup that takes two minutes across three tabs looks like a small thing, until it happens sixty times a week. Then it stops looking small.

Run the rough math. If the average customer question needs three minutes of tab hopping to gather context, and a support day answers thirty such questions, that is ninety minutes a day spent only on gathering. Before a single reply is written, that time is already gone.

A year of that is hundreds of hours. For a small team, that is the difference between adding a part-time hire and not. The hours come back as better replies and calmer days when the context arrives on one screen. The number worth tracking then is context time per ticket.

Frequently asked questions

How Do I Measure This In My Team?

Track the tool visits needed to gather context for one ticket, multiply by weekly ticket volume, then estimate the minutes. Ziikly removes most of those visits by querying every connected tool in a single email search. The same measurement shows the before and after.

Is tab switching really a big enough cost to fix?

Yes, because the cost multiplies. A two minute lookup repeated sixty times a week is two hours a day of pure context gathering, plus the attention loss each switch causes. Small per switch, but large per week and enormous per year.

Support Workflow For A Founder Doing Everything

Emil — Mon, 07 Sep 2026 19:00:18 +0000

When you are the founder, the product builder, the marketer and the support team all at once, support can consume your entire day. The inbox opens and thirty small requests each pull you away from the work that actually moves the company forward. The answer is not to ignore support; it is to run it like a deliberate system with fixed windows, batched work and as little context gathering as possible. Ziikly is built for exactly this, letting a solo founder see payments, orders and conversations in one search instead of five logins.

Two Fixed Windows Beat Constant Checking

The most expensive support habit is checking the inbox all day. Every glance breaks your focus, and a founder's focus is the scarcest resource in the company. The fix is a boundary, not a tool, and the boundary has to be set once and held every day.

Pick two windows a day, morning and afternoon, and handle support only inside them. Reply to everything within each window, then close the inbox and work on the product. Customers adapt to the rhythm quickly when the replies stay fast and complete, and consistency beats constant availability.

Set expectations honestly in your replies and on your site. A stated response time of a few hours beats silent delays, and it protects your day from being ruled by the inbox. An honest promise is the cheapest way to earn patience, and it makes the windows feel fair to customers.

Batching Similar Requests Together

Inside the window, work in batches by type instead of jumping between unrelated requests. Answer all the access questions, then all the billing questions, then all the others. The order keeps the mental model warm and the replies consistent, and batching turns a messy hour into three short tasks.

Batching keeps the relevant context warm. When you answer ten access questions in a row, you already know the enrollment flow, the common failure and the standard reply. The next one takes less time than the first, which is exactly where the savings live, and the window shrinks as the pattern repeats.

The batches also expose patterns. Ten access questions in one window usually means one shared cause, a broken link or a bad onboarding step, and finding that cause matters more than the individual replies. The batch is product feedback you did not have to pay for.

Knowing When To Hire Help

The tipping point for hiring support help is not a ticket count; it is the shape of your day. If support windows keep overflowing, if the backlog never clears, or if product work keeps losing to the inbox, the math has changed even if the raw volume looks ordinary.

A rough benchmark helps. One founder handling a focused batch of tickets across two windows can sustain a few dozen requests a week. When the volume reliably exceeds that, the first support hire stops being a cost and becomes a reallocation of the scarcest resource you have: your time.

The hire works best when the context is easy to hand over. A new support person should see what you see: the same payments, orders and history from one lookup. That makes them useful from the first week, not the third month, and product knowledge grows on top of the shared record.

Frequently asked questions

How Many Tickets Can One Person Handle?

A founder running two focused batches a day can sustain a few dozen requests a week while still building the product. When volume reliably exceeds that or the backlog never clears, it is time to bring in help rather than to simply work longer hours.

Will customers accept fixed reply windows?

Yes. Customers value a fast, complete answer more than an instant one. A stated response time of a few hours, with consistent results inside those windows, builds more trust than unpredictable all day monitoring. Trust compounds exactly where consistency lives.