Skip to content
← All insights
REVENUE·May 7, 2026·4 min read

The chat that pays for itself

Most support chat is a cost centre because nobody can see the revenue it earns. We rebuilt the layer underneath so every conversation is tied to a Stripe charge.

Walk into any board meeting where support chat is on the agenda and watch the temperature drop. Not because nobody believes in support — everyone believes in support — but because nobody can defend the line item with a number. The CRO can show pipeline. The CMO can show acquisition. The head of support can show ticket volume and CSAT. None of it adds up to the question the CFO actually asks: did this thing make us money?

Support chat is a cost centre because the integration to revenue was never built. Not because the value isn't there.

The piece nobody ships

The standard architecture: chat tool sits in your site, captures conversations, sends transcripts to a CRM if you're lucky. Stripe sits somewhere else, charges customers, sends webhooks to your billing dashboard. The two systems share a common visitor — the one in front of the screen — but they never share areference. There's no foreign key from the conversation to the purchase. So when the purchase happens, there's no way back.

You can fake it with email. If the buyer's Stripe email matches an email captured during chat, you have a probabilistic link. But buyers use their work email at checkout and their personal email in chat. Or they don't give an email at all. Or the chat happened a week before the purchase and the email field never came up.

Cookie-first attribution, in two moves

Chatified now drops a first-party chatified_visitor_id cookie on the merchant's domain. The cookie value is the visitor UUID we already use for everything else — chat threads, identity graph, intent score. It's already there; we just made it readable from the merchant's checkout server.

Move two: when the merchant creates a Stripe Checkout session, they read the cookie and forward it as metadata.chatified_visitor_id. Six lines of code in their checkout route. The Stripe webhook fires, we see the metadata, we tie the charge to the visitor by direct UUID match. No email guessing. No probabilistic join. The visitor who chatted on Tuesday is the customer who paid on Thursday.

What this looks like in the inbox

Every conversation row gets a $NN.MM chip when revenue lands. Refunds write a negative-cents reversal so net revenue stays honest. The Analytics page now answers a question your old chat tool could not: which channel produces customers, not just conversations? Filter to first_utm_medium = paid and watch the revenue column either justify the ad spend or quietly indict it.

The cookie is also the safety net for everything we ship next. Outbound campaigns can address customers we know paid us before. Lookalike modelling has labelled positives. The intent score has ground truth to calibrate against. The integration to revenue isn't a feature — it's the fact that finally lets the rest of the system tell its story.

Like the way we think? See it shipped.Start 7-day trial
KEEP READING
CAMPAIGNS·3 min

Outbound from the inbox

Inbound chat is half the conversation. Once you know who's on the site and what they care about, the inbox should be able to speak first — to the right people, on its own terms.

PHILOSOPHY·4 min

Why we charge by resolution, not by seat

Seat pricing is a tax on having a support team. We chose a model that pays Chatified only when the agent actually answered.