Home / Blog / A CRM built from your pixel and your inbox

CRM

A CRM built from your pixel and your inbox

Audiences from behavior rather than uploads, journeys the inbox can see, and outreach where consent is checked at the moment of sending, every time.

AUDIENCES AND CONSENTA CRM built from yourpixel and your inboxOrkie

A store CRM is usually a contact list with tags, fed by whatever the email tool exported. It knows who bought. It does not know who looked at three product pages and left, who reached checkout twice, who asked a fitment question by email last week, or whether any of those people ever agreed to be marketed to. This post describes a CRM that is built from the pixel and the inbox rather than beside them, and what that changes about audiences, journeys and outreach.

The CRM is the index, not the archive

The design choice is simple. The CRM does not copy your orders, page views and emails. It keeps the identity links between them and compact facts about behavior: which paths were viewed, which products were carted, which form was submitted, which source and campaign brought the person. The pixel keeps the raw sessions. The store keeps the orders. The inbox keeps the messages.

That makes the CRM the place where one person's history from every module lines up on one timeline: a Google click in March, a product view, a cart, an abandoned checkout, a support email, an order, a return, a YouTube comment. Each entry links back to the module that owns the detail.

It also means the CRM can be honest about what it does not know. A missing consent record is unknown. It is never guessed as yes.

Audiences from behavior, not from uploads

Because the behavior facts are in the CRM, audiences can be built from what people did rather than from a list you exported. A dynamic audience is a rule. A static one is a list you manage. The workspace ships with a starter set that most stores use as is:

AudienceRule in plain English
Added to cart, never orderedCarted something, no completed order, no refund proving a prior purchase
Abandoned checkout, never orderedAt least one checkout still open after 30 minutes or marked abandoned
Viewed products, never orderedProduct views, no order
Customers with an open cartBought before and likely has items in the cart now
Lapsed customersBought before, nothing in the last 90 days
Repeat customersMore than one order
VIP customersTop spenders by lifetime value
Refund or return riskPattern of returns

Rules can also use contact fields, relationship ratings, spend totals, refunds, pixel forms and pages, commerce summaries, communication facts and any custom field. A checkout on one store closes only the matching cart on that store; activity elsewhere cannot erase it. Money stays separated by currency.

Every rule is previewed before it is saved, with the fields it checked and any warnings. Memberships refresh in the background as contacts and rules change. If a source module is briefly unavailable, the last decision shows as stale rather than wrongly removing someone.

Say your store has 60,000 contacts. An illustrative starter set might put 4,000 in "abandoned checkout, never ordered," 9,000 in "lapsed," and 700 in "VIP." Those three groups want three different messages, and none of them came from a spreadsheet.

Journeys the inbox can see

The customer card sits inside the inbox. When a support message arrives, the person answering it, or the AI drafting the reply, sees the timeline: orders, open cart, prior conversations, the source that brought them. When a cart-recovery email goes out, the reply lands with the cart and the email attached, and the CRM logs both.

The link runs the other way too. A form submission on the storefront creates or updates a CRM lead. A back-in-stock request adds a timeline entry and a watched product, without subscribing the person to marketing. A help request, a saved cart, a chat: each shows up as a fact the next conversation can use.

Deals, activities and follow-up tasks are there for stores with a B2B side, a phone line, or a showroom, and they attach to the same contact.

Consent is checked at the moment of sending, every time

This is the part that separates a CRM built for outreach from one built for lists.

Every contact carries consent state per channel. Email marketing consent is recorded only when a shopper checked a separate marketing box and the disclosure was captured. A newsletter checkbox on a back-in-stock form is not consent. A "notify me" is not consent. Unsubscribes, bounces, complaints and manual exclusions are imported from whatever tool you used before and kept as suppressions.

Then, at send time, the check runs again. An email lane pulls its members from an audience, and the CRM re-checks consent and suppression for each person immediately before the message goes. A shopper who signed up on Monday and unsubscribed on Tuesday does not get Wednesday's email. A restriction or erasure request blocks delivery.

Advertising audiences have their own policy. An admin chooses between explicit consent only and a first-party opt-out rule for US customers, and the second one does nothing until the admin acknowledges that the privacy notice discloses sharing with ad platforms and records where. Exclusions apply in either case: a refusal, a suppression, a Global Privacy Control signal from any of the person's devices, a known minor, a sensitive category, an inactive contact, or a region that requires opt-in. The pixel feeds the CRM the region and the browser opt-out signals for known customers within minutes, so the CRM does not wait for a nightly sync to learn that someone said no.

Sending an audience anywhere is a proposal

When an audience goes to an ad platform or an email lane, the CRM creates a proposal first. It shows eligible members, suppressed members, missing-consent members and stale members. Nothing is sent. A person reviews the counts, records why, and approves. The check runs once more, and only hashed identifiers leave the workspace, never raw emails. Send history shows every run and what the destination said.

Only a person can approve a send. An automation can resume a send a person already approved. It cannot approve one.

Ask the CRM a question

With Workspace MCP connected, an admin can ask Claude or ChatGPT: "How many contacts can we email or text right now?" The answer is based on recorded consent and active suppressions, with unknowns counted as unknown. "Show me this customer's timeline." "Preview an audience of people who viewed the wheels collection twice and never ordered." Reads answer immediately. A change is shown exactly before it runs, and a high-risk change waits for a different admin to approve it.

Where to start

The CRM is most useful after the pixel has run for a few weeks, because that is when the behavior facts exist to build audiences from. Import your suppressions before the first send. Turn on the starter audiences, look at who is in them, and pick one, usually abandoned checkout, for the first lane. Let consent be the gate, not the afterthought.

Want a CRM that knows what your customers did? Talk to us.


Want this for your business? Talk to us How the pixel works

Keep reading

RELATED PRODUCTSRelated products thatactually fitOrkie
Feeds

Related products that actually fit

Most "you may also like" widgets guess. Set related-product rules in plain words, like same brand or parts that fit, and measure what they really sell.

Sep 27, 2026 · 4 min read
AI SEARCHHow to get your productsinto ChatGPT answersOrkie
Feeds

How to get your products into ChatGPT answers

What AI assistants read, how to feed them one clean catalog, and how to see the sales ChatGPT, Gemini and Perplexity send you.

Sep 27, 2026 · 5 min read
HOW IT WORKSHow Orkie's pieces worktogetherOrkie
AI Workspace

How Orkie's pieces work together

The pixel steers the feeds, measures related products and tells the Outbox what each shopper left behind. CRM lists become ad audiences. The company brain keeps learning.

Sep 27, 2026 · 6 min read

Get new posts by email

One or two a month. No hype, no spam.