Customer-side observability: seeing a company the way its customers do

Customer-side observability is seeing what a company does to its customers by being one of them: every email, text, price, page, checkout and AI answer it sends, kept over time with evidence anyone can check. AI customers are how it is done: AI agents that become real customers of a company, wait for what arrives and keep it as evidence.

Engineering teams can see inside everything they run: every request, every error, every slow page. They can’t see what their customers receive, because most of it travels through systems they don’t run: the email platform, the SMS provider, Gmail’s tabs, the chatbot vendor, the payment page.

Customer-side observability fills that gap. It watches a company from where its customers stand, at your own company and at any other, and keeps what arrives as evidence. AI customers are the instrument that does it.

What customer-side observability is

Customer-side observability is seeing what a company does to its customers by being one of them: every email, text, price, page, checkout and AI answer it sends, kept over time with evidence anyone can check.

OpenTelemetry defines observability as understanding a system from the outside, and builds it from telemetry: data emitted from a system and its behaviour, as logs, metrics and traces. Customer-side observability takes the same idea to a different system: the whole company, as its customers experience it. Its telemetry is what the company sends and shows them.

Its 3 pillars

• Presence. A real customer identity at the company: an inbox, a phone number, a browser and the accounts it opens. Only a customer receives what customers receive.
• Provenance. Each item kept as it arrived, with its time, and for email the sender’s authentication checked on arrival, so the record still holds when it is opened months later. Bulk senders to Gmail must authenticate their mail under Google’s sender guidelines.
• History. Weeks and months of what arrived. What a company sent last month can’t be collected today.

The instrument is the AI customer. An AI customer is an AI agent that becomes a real customer of a company, with its own inbox, phone number and browser, and keeps what the company sends and shows it as evidence. It is asleep almost all the time and wakes only when the company sends something or a check is due, so it can watch for months at almost no cost.

How it differs from the observability you already run

Each of these practices does its job well, and most teams need several. They differ in what they watch and where they watch it from.

• Real user monitoring gives end to end visibility into the real time activity and experience of individual users on your own site or app. It stops at your site’s edge: it can’t see the email that follows a visit.
• Client-side observability exists because, as OpenTelemetry puts it, traditional server side monitoring misses the complete picture of user experience. It still covers your own apps.
• Synthetic monitoring runs simulated requests through paths someone scripted. It checks that a path works. It doesn’t sign up, wait for days and open what arrives.
• AI agent observability records each request to your AI agent as a trace, which shows how the agent reached an answer. Customer-side observability shows what a customer was told.

Why it matters now

• The journey runs on other people’s systems. Email platforms, SMS providers, review apps, chat vendors and payment pages each hold part of it, and each reports only its own part.
• The money is in private channels. Klaviyo’s own 2026 benchmarks put automated flows at 5.3% of email sends and nearly 41% of email revenue.
• What companies intend and what customers receive differ. A test of 362 ecommerce brands by Joy Joya found 158 sent no welcome email to a new subscriber.
• AI agents now speak for companies. The UK’s Competition and Markets Authority tells businesses to regularly check how well an AI agent is performing, and holds them responsible for what it does.

The customer-side signals worth watching

Treat each journey like a service with a target. Write the pass mark down before the first check, so a result is a pass or a fail and never an opinion.

For developers: building on customer-side observability

A customer-side observability system has 5 parts: identities, sign up, durable waiting, an evidence store and facts delivered where they are used.

1. Identities. An inbox per company (a Gmail inbox, if you need the tab), a phone number per market, and a browser for pages and checkout.
2. Sign up. A program per platform, learned once and replayed, with an agent only for an unusual form. Most companies use a few platforms, so a few programs cover most of them.
3. Durable waiting. Event driven state that sleeps until mail, a text or a timer arrives. On Cloudflare, Durable Objects that are idle and eligible for hibernation are not billed for duration, so a month of waiting costs almost nothing.
4. An evidence store. Append only, with each raw email, its headers, its DKIM result and a hash, and each page capture with its time and address.
5. Facts. 1 sentence each, typed, with a link to the evidence, sent to a webhook, a queue, Slack or your own agent.

For a handful of companies, a developer can assemble this from an inbox service, a browser service and a scheduler in a few days. At thousands of companies, the long tail of sign up forms, cheap waiting over months and the history nobody can backfill become the work.

Obsession exposes this as 5 verbs over MCP, an API and an SDK: lookup, facts, evidence, become_customer and notify. The runtime is open source, and Obsession can run millions of AI customers. More is in AI customers for developers.

For CX teams: journeys and AI agents

A CX team owns what customers live through, and most of it happens in tools the team doesn’t run. Customer-side observability turns each journey into checks with a pass mark, run every day and after every change: the welcome, the reminder, the order confirmation, the delivery message, the password reset, the support reply.

AI agents need the same treatment. A support bot, a voice agent or an AI SDR can change its answer after a prompt edit, a new help article or a model update. Test customers asking the same questions every day, and within the hour of any update, show what customers are told, with the transcript. The method for a store’s chatbot is in how to test your store’s chatbot.

For every business: your rivals and your market

Customer-side observability works on any company, so the same practice covers your market. Every rival’s emails, texts, offers and prices on 1 timeline (Competitor tracking). What each prospect does to its own customers before a sales call (Prospect intelligence). The partners and deals sites showing your codes, and what AI assistants say about you (Listings and AI answers).

A 30 day plan

1. Week 1. List 5 journeys that earn or lose money (welcome, basket, checkout, delivery, support) and 5 rivals. Write a pass mark for each journey.
2. Week 2. Run each journey once as a new customer, by hand or with AI customers, and record what arrived and when.
3. Week 3. Send each result to where the team works: a Slack channel, the CRM or your own agent. Add the check after every release.
4. Week 4. Review what failed, what it was worth (the flow’s revenue a day × the days it was silent) and which checks to run daily.

Limits

• It sees what customers receive, and not why. The cause of a missing email sits in the company’s own tools and its own observability.
• A new customer sees what new customers get. Engaged, long standing customers can receive other emails and other placement.
• It stops at a bot wall or a CAPTCHA, and names the step it couldn’t test.
• It complements system observability. Uptime, errors and performance stay with the tools built for them.

Questions about customer-side observability