# Welcome iCustomer Platform documentation: the always-on system that decides what to do for your audiences, acts across your channels, and proves what worked. iCustomer Platform is your always-on AI marketing team: it listens to your market, decides what to do for each audience, acts across your channels, measures the outcome, and learns. Around the clock. New here? Start in order:
1. What iCustomer Platform isThe two-minute answer: what it does, and what it is not./pages/06Djm9R6EeCBPtWqK0WZ
2. The loop in one pageHow a goal becomes an outcome, and what you see when it cannot./pages/6yADxv95YmuJzf6RGGTn
3. Quick start: B2BThirty minutes from your domain to a first play approved./pages/tt2xxwfMa59XdFVnoa1E
3. Quick start: D2CInstall your pixel, connect your stack, go./pages/z4Xe5856ZN2gAnCQaJiD
PlansThe four plans, and what each unlocks./pages/MWpD2V2gIBjK4PTbwlD5
# What iCustomer Platform is iCustomer Platform is the always-on Intelligence system above your channels: audience intelligence, signals, decisions, and causal measurement. You already have campaign tools. Paid media, email, programmatic: each runs its own bids, manages its own creatives, and reports its own results. The problem: every tool grades its own homework. Each shows you the numbers that flatter it, none sees your whole funnel, and none is accountable to your goals, target and outcomes. iCustomer is not some campaign tool, and neither a CDP. A CDP stores and segments your data and waits for you to decide. iCustomer is the "always-on intelligence system" that sits *above* your channels and does the deciding, and it is built around three things. ## Audience intelligence Who your audiences are: your ideal customer profile, personas, and fit, built from public information about your company and enriched by your connected tools like CRM and ad accounts. It stays fresh on its own. This is the **who**. ## Signals and decisions The buying signals your audiences throw off, captured and scored with FIRE (Fit, Intent, Recency, Engagement) so you know who is Hot, Warm, or Cold right now, and the decisions that follow. Decision-first: the system decides what to do for each audience before it picks a channel. A demo request, for example, lifts Intent, flips an account to Hot, and triggers the next move. This is the **why now** and the **what to do**. ## Unified measurement One honest scoreboard. Every event, decision, and outcome is tied together and graded independently of what each tool says about itself, across all your channels. This is the **what actually worked**. ## Three names to know * **iHarness**: the agent running your growth loop. It executes, within the guardrails you set, rather than only suggesting. * **Growth Brain**: the self-learning context iHarness runs on. Everything you connect accrues into it. It sits on your data infrastructure, your CRM and your warehouse, and does not replace it. * **iReveal**: identity, outcomes, and causal proof from your own site traffic. In one line: iHarness runs on your Growth Brain. It works where your team works: the web app, Slack, and agents connecting in. Enterprise runs in your cloud or warehouse. SMB runs in ours. Same architecture, different home. The full picture is in [System architecture](/concepts/system-architecture). ## What it doesn't do iCustomer doesn't run your media buys, send your emails, or make your creative. Those stay where they are: in each channel tool, with your campaign manager, agency, or with your GTM lead. You don't staff a full team. You get an AI data and decision scientist working on your data & outcomes, so your creative and brand people can keep doing what they do best. ## The thesis You can't grade your own homework. The tool that spends the budget shouldn't be the one telling you it worked. Audience intelligence and signals lead to decisions, decisions lead to actions & outcomes, and outcomes are measured honestly, so you win on the revenue you're after, not the vanity metrics each campaign tool reports about itself. Next: [The loop in one page](/getting-started/the-loop). # The loop in one page How iCustomer Platform turns a goal into an outcome and back again: five steps, and an honest answer at every point it cannot advance. Every marketing team asks the same two questions: am I winning, and what's my next move? Most tools answer half. Dashboards tell you where you stand and cannot act. Automation runs work and cannot tell you whether it helped. iCustomer Platform closes that gap by running one loop, continuously, over your business: ```mermaid %%{init: {'themeVariables': {'lineColor':'#98A2B0','edgeLabelBackground':'#E4EAF3','textColor':'#1f4f9c'}}}%% flowchart LR G(Goal) --> K(KPI) K --> T(Target) T --> P(Play) P --> O(Outcome) O -. credited back through identity .-> T classDef box fill:#E4EAF3,stroke:#2966BC,color:#1f4f9c class G,K,T,P,O box ``` * **Goal**: one of [six standing GTM ambitions](/iharness/goals-kpis-targets), with one primary and up to two secondaries. The goal orients the whole loop. Every KPI is read in its service, and every decision is made to advance it. * **KPI**: what your connected sources can actually read. Measurability is the definition: if nothing you've connected can compute it, it isn't a KPI for your workspace. This is why connecting a source doesn't just add data, it unlocks goals. * **Target**: a number worth committing to, with a deadline, a guardrail that stops it being won the wrong way, and a checkpoint that tells you early if the plan is wrong. Achievability is part of the definition: a number nothing can reach isn't an ambitious target, it isn't a target. * **Play**: a repeatable motion that moves a KPI. Several plays can move the same KPI through different mechanisms, which is why choosing one is a diagnosis rather than a lookup. * **Outcome**: what actually happened, measured against what was expected. The difference between the two is what the system keeps. ## Why the loop closes An outcome happens to one person or one account. A KPI is a number about a population. For an outcome to credit back to the target it served, the platform has to know that this person and that account are the same entities it was working on when it decided. That's why identity resolution sits underneath everything rather than off to the side in data hygiene: it's the join that lets the loop close. When identity doesn't resolve, the outcome is still counted and still reported, credited to nothing, and said out loud. It is never quietly dropped. ## What you get One loop, running over your business, returns four things: * **A number worth committing to.** Targets are computed from what your connected data can read and what your plays can move, never guessed. * **The right move, diagnosed.** The play that matches the cause behind a slow number, not a lookup from a menu. * **A receipt for every action.** Why it ran, what it expected, and what came back, on record before it runs. * **An honest answer when it cannot advance.** At every step the platform either moves forward or tells you exactly what is in the way and what would unlock it. Those moments arrive in [Pulse](/pulse/queue). ## The meta loop Underneath the first, a slower loop runs and never closes: **outcome → evidence → better targets, better play choice.** The first loop runs in roughly 90 days. The meta loop runs across quarters, and it is where the compounding lives. Concretely: when a target closes, the platform records what that play actually delivered in your workspace. Your own measured result then outranks any published benchmark the next time it sizes something. The bar moves as your business gets better, instead of the product going quiet after the first win. [The compounding loop](/measurement-and-outcomes/compounding-loop) follows the meta loop through measurement. {% hint style="info" %} The loop is continuous by design. Continuous, always-on operation over your managed audiences is a Team capability. On Free and Pro, the same loop runs on request. {% endhint %} ## Where to go next * [**Core concepts**](/concepts/core-concepts): the terms this loop is built from. * [**System architecture**](/concepts/system-architecture): the five layers the loop runs on. * [**Data flow and trace spine**](/concepts/data-flow): how a single event travels. * [**Plans**](/getting-started/plans): what each plan unlocks. # Plans Four plans, from free to fully custom, and what each unlocks. Four plans. Start free, upgrade when the loop earns it. * **Free** is for seeing it work: install the pixel, see who visits by name, build your first audience. Single-player; it stops when the credits run out. * **Pro** adds room to run: more credits, a small team, and the loop working your goal. * **Team** is the full always-on system across a growing team and multiple workspaces, with overage available so the loop never stalls mid-month. * **Enterprise** is custom: your scale, your deployment, your terms. [Book a demo](https://www.icustomer.ai/contact). Credits are the single unit of usage, drawn as the system works and shared across the owner's workspaces. The mechanics, categories, overage, and plan changes live in [Billing](/settings/billing). {% hint style="info" %} Prices, credit allotments, and seat counts live on [icustomer.ai/pricing](https://www.icustomer.ai/pricing). {% endhint %} # Quick start: B2B B2B in your first thirty minutes: from your domain to a first play approved, with its reasoning on record. Thirty minutes, no admin rights, no data engineering. The goal is one arc: see your audience, approve one play, and read the reasoning behind it. {% stepper %} {% step %} ### Paste your domain Sign up and give [iHarness](/iharness/what-it-does), the AI you will work with, your company URL. It researches your business and drafts your **ABC Card**: your Audience, Brand, and Competition, every claim with its source. {% endstep %} {% step %} ### Confirm your card and goal Fix anything that is off and confirm. Your goal is captured at sign-up and reflected on the card with a provisional target. Confirmation is the one hard gate; everything after builds on it. {% endstep %} {% step %} ### Connect your CRM, or skip it Connect HubSpot or Salesforce and your real customers sharpen everything. No CRM handy? Start from market data; the connection can come later without redoing anything. {% endstep %} {% step %} ### Meet your audience iHarness sizes your market, finds the right accounts and the right people at them, and scores everything with [FIRE](/audience/fire-scoring), reasons attached. {% endstep %} {% step %} ### Approve your first play You get your audience and ready-to-run play proposals. Pick one, review what it will do and what it needs, and approve. Nothing runs without you. {% endstep %} {% step %} ### Read the receipt Open the decision behind the play: what it saw, what it chose, what it expects. That receipt is the habit worth building; everything in the platform answers "why?" {% endstep %} {% step %} ### Install your pixel One async tag on your site reveals who is visiting by name and closes the measurement loop. Everything above works without it; with it, your decision traces carry the visitor evidence they would otherwise lack. See [Events and pixels](/integrations/events-and-pixels). {% endstep %} {% endstepper %} From here, the loop is live: it keeps your context fresh, watches your audience, and raises a hand in [Pulse](/pulse/queue) when something needs you. # Quick start: D2C D2C in three moves: install your pixel, connect your stack, go. Three moves: install your pixel, connect your stack, go. {% stepper %} {% step %} ### Install your pixel One async tag on your site. Within minutes you see who is visiting, resolved to real people and companies, not sessions. See [Events and pixels](/integrations/events-and-pixels). {% endstep %} {% step %} ### Connect your stack Your email platform, your ad account, your store's data. Each connection makes the picture sharper and gives the loop somewhere to act. {% endstep %} {% step %} ### Go [iHarness](/iharness/what-it-does), the AI you will work with, builds your first cohorts from what the pixel and your tools reveal, and proposes what to run. Approve, and the loop is live: watching, deciding, and reporting what actually worked. {% endstep %} {% endstepper %} Questions along the way go straight to [iHarness](/iharness/ask-iharness), in the app or in Slack. # Glossary The short glossary, in loop order: the words you'll meet in your first session. The short version, in the order you'll meet each idea. The exhaustive A-to-Z lives in the [Reference glossary](/reference/glossary). | Term | Meaning | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **The loop** | The always-on cycle behind everything: capture, resolve, score, decide, attribute, then back to the top. See [The loop in one page](/getting-started/the-loop). | | **iHarness** | The AI you talk to. It reasons over what the system knows, decides, and coordinates the work. See [What iHarness does](/iharness/what-it-does). | | **Agents** | The specialists working behind iHarness, each covering one part of the loop. You see them as bylines on delivered work. | | **ABC Card** | The picture of your Audience, Brand, and Competition, built from your domain during onboarding. You confirm it, and it becomes working context. | | **Growth Brain** | The self-learning context iHarness runs on: everything you connect, and every outcome, accruing in one place. | | **Audience** | Everything the system watches and acts on for you: the audiences you have under management. See [Always-on monitoring](/audience/monitoring) for what under management means. | | **Cohort** | A named group under a segment (B2B or D2C), defined by a shared trait or behavior. What you build and activate. | | **Signal** | An event that tells the system something changed: a site visit, a demo request, a funding round. | | **FIRE score** | Fit, Intent, Recency, and Engagement, rolled into Hot, Warm, or Cold, so you know who is worth acting on now. See [FIRE scoring](/audience/fire-scoring). | | **Goal** | One of six standing go-to-market ambitions. Goals never expire. | | **KPI** | The number a goal moves, readable from your connected data. | | **Target** | A specific commitment under a goal: a number and a date the loop paces toward. | | **Play** | A proven motion from the library, made yours: the running automation. Plays have runs. | | **Activation** | What a run delivers into a channel: the live push of an audience to LinkedIn, Instantly, or your CRM. | | **Decision trace** | The receipt behind any action: why, on what evidence, and what came of it. See [Decisions and traces](/concepts/decisions-and-traces). | | **Outcome** | What happened, measured against what was expected. Outcomes move targets, and targets move KPIs. | | **Pulse** | Where the system raises its hand when something needs you. See [The queue](/pulse/queue). | | **Credits** | The single unit of usage every plan includes. See [Plans](/getting-started/plans). | # Core concepts The ten ideas the platform is built on, in the order the loop uses them. Ten ideas, in the order the loop uses them. Each is defined here once, and the product sections describe where you meet it. ## Context Everything the system knows about your business, held in the Growth Brain: your audience, brand, and competition, seeded from public information at onboarding, confirmed by you, enriched by your connected tools, and sharpened by every outcome. Every claim carries its source, and what you say always outranks what was inferred. See [Context and memory](/concepts/context-and-memory). ## Goals, KPIs, and targets A goal is a standing ambition, one of six, and it never expires. A KPI is what the business can actually read: if no connected source makes a number readable, it is not a KPI for your workspace. A target is an achievable, computed commitment under a goal: a number and a date. Outcomes move targets, and targets move KPIs. See [Goals, KPIs and targets](/iharness/goals-kpis-targets). ## Identity One person is one record, one company is one account, no matter how many fragments arrive. Verified matches earn an immutable OneSource ID. Everything else attaches as an alias. Identity is what lets an anonymous click and a closed deal turn out to be the same story. See [Identity](/audience/identity). ## Audience The accounts and contacts under management: watched, scored, and acted on continuously. Audiences are organized as cohorts under two segments, B2B and D2C. See [Building and sharing audiences](/audience/building-audiences). ## Decisions The unit of work. A decision is a moment where the system chose one option over others, spent something finite doing it, and said what it expected to happen. Anything without all three is just a step. See [Decisions and traces](/concepts/decisions-and-traces). ## Plays The motions. A play is a named, repeatable piece of work that moves a KPI: picked from the library, made yours, and running against your audience with runs and activations. Running a play produces decisions. See [What a play is](/plays/what-is-a-play). ## Pulse The attention layer. The system works in the background and raises its hand only when something needs a human: an approval, a problem, a moment worth marking. See [The queue](/pulse/queue). ## Measurement The honest scoreboard. Every event, decision, and outcome joins on one trace ID, so results are graded independently of what any channel reports about itself. See [Traces and receipts](/measurement-and-outcomes/traces-and-receipts). ## Outcomes and learning An outcome is what happened, measured against what the decision expected. The difference between the two is a learning, recorded so the next decision is better. This is why the system compounds instead of going quiet. See [The compounding loop](/measurement-and-outcomes/compounding-loop). ## The loop The shape that holds it all: capture, resolve, score, decide, attribute, then around again. Context feeds decisions, decisions produce outcomes, outcomes sharpen context. See [The loop in one page](/getting-started/the-loop). # System architecture How iCustomer Platform is put together: iHarness running the loop on your Growth Brain, the five layers underneath, and the four rules that keep your systems yours. iHarness runs on your Growth Brain. Everything else in the picture exists to feed that loop or to keep it honest. ![iCustomer Growth Brain: how it connects to your stack](/files/OoA4hARXQ9ssoGdLmTm0) ## How to read it It is a loop, top to bottom and back. A goal comes in at any surface. iHarness runs the loop on the context the Growth Brain holds. Audience decides who. Decisions decide what. Every decision passes through the guardrails strip before iConnect carries it out in your systems. Measurement proves what worked, and outcomes flow back into the Growth Brain. That return path is the self-learning part: it is how the system works, not a feature label. ## The five layers | Layer | What it is | In one line | | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------- | | **1. Surfaces** | Where your team already works: the web app, Slack, the Snowflake native app, and agents connecting in. An access layer, not a product. | Works where your team works. | | **2. iHarness** | The agent running the loop. It holds three things: your goals and targets (without a goal, nothing runs), Pulse (the human channel: alerts, approvals, autopilot settings), and Orchestration (runs plays through agents, and plays live here). | The agent running your growth loop. It executes, within guardrails. | | **3. Growth Brain** | The self-learning context: customer, company, and audience, built on OneSource identity, accruing from every connected system and every decision outcome. iHarness's memory and the Growth Brain are the same thing. It holds three capabilities, covered next. | Everything you connect accrues into one self-learning context. | | **4. Guardrails & governance** | The strip between Decisions and iConnect: observability, evals, sandbox, decision traces. Every decision passes through it before touching your systems, and every outcome passes back through it. | Sandbox first, evals always, every decision traced. | | **5. iConnect** | Integrations. Activation out, governed connection in. Both directions, one layer. | Connects your stack: governed, both ways. | ## Inside the Growth Brain The third layer holds the three capabilities the loop is made of. They are the three boxes in the middle of the diagram. | Capability | What it does | In one line | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | **Audience + Signals** | Who and when. FIRE scoring (Fit, Intent, Recency, Engagement), cohort building, and the first-, second-, and third-party signal feeds that drive them. | Decides who to act on and when, scored by FIRE. | | **Decisions** | The unit of work. Produced by plays, traced, and approved by you or by a policy you set. A specific, auditable action, reversible where the channel allows. | Every action is a traced, approved decision. | | **Measurement** | Did it work, causally. Two feeds, what each channel says happened and what iReveal proves happened, reconciled. | Causal proof, not last-touch attribution. | ## Below the platform: your stack Below the five layers sits your stack: your first-party systems (CRM, data cloud, drive, code, ESP, campaign tools), the media platforms where activation lands (LinkedIn, Meta, Trade Desk, Google), and 50+ third-party data vendors, resolved to OneSource IDs. Your data stays yours. Licensed data arrives resolved, never raw. The Growth Brain is not a CDP, a data lake, or a warehouse. It sits on your data infrastructure and does not replace it: the decision layer above the data cloud. {% hint style="info" %} **Common use cases.** Discover accounts and contacts always-on per ICP, monitor the intent of your ICP, prioritize on FIRE, route leads and govern contacts, and de-anonymize website visitors to prove outcomes. The plays that carry them are in the [Play library](/reference/play-library), and the visitor side is [iReveal](/ireveal/overview). {% endhint %} ## Where it runs * **Enterprise** runs in your cloud or warehouse. * **SMB** runs in our managed cloud. Same architecture, different home. "Zero egress" is the Enterprise shorthand, and it carries its scope: no warehouse data leaves except governed, customer-approved activations. Activation is egress by design. That is what you are running it for. ## Four rules the architecture enforces * **Only iConnect touches your systems.** Nothing writes around it. * **Every write to your systems is a decision**: traced, approved by you or by a policy you set, and reversible where the channel allows. * **Every decision passes the guardrails strip before it runs.** No exceptions for small actions. * **Third-party data never crosses raw.** Licensed data from the vendor layer enters only by resolving to OneSource IDs, and is never written raw into your CRM or media accounts. The missing arrow between the vendor layer and your systems in the diagram is deliberate: it is the compliance story. ## One diagram, three grains The loop runs at population grain over roughly 90 days: a commitment, from goal to outcome. [Data flow](/concepts/data-flow) runs at individual grain in seconds: one event, from capture to attribution. The five layers above are the machinery both run on. They meet at Audience, where one event becomes one identity, and identities become the population a KPI is a number about. ## Where to go next * [The loop in one page](/getting-started/the-loop): the path through these layers. * [Data flow and trace spine](/concepts/data-flow): the individual-grain path. * [Decisions and traces](/concepts/decisions-and-traces): what Decisions produce. * [Context and memory](/concepts/context-and-memory): how the Growth Brain ranks what it knows. # Context and memory What the system knows and what it has learned: sources, precedence, and why what you say always wins. Everything the system knows lives in one place: the **Growth Brain**, the self-learning context iHarness runs on. Everything you connect accrues into it, and every outcome comes back to it. * **One store, not two.** iHarness's memory and the Growth Brain are the same thing. * **Not a CDP, a data lake, or a warehouse.** It sits on your data infrastructure and does not replace it. Inside it, two kinds of knowing: * **Context** is the current picture of your business: your audience, brand, and competition, your funnel, and anything you have told the system directly. Context can be handed over. * **Memory** is what the system has learned by running: which signals mattered, which moves worked, what your team approves and rejects. Memory has to be earned. ## Where context comes from Context is seeded from public information about your company, then sharpened by your connected tools and by you. Every claim carries its source, and claims that could not be verified are presented as questions rather than stated as facts. ## Which source wins When sources disagree, precedence is fixed and human-first: 1. **What you have declared.** A correction from you outranks everything, permanently. 2. **Your CRM.** Your system of record beats anything inferred. 3. **Observed signals.** What actually happened on your site and channels. 4. **Enriched and public sources.** Useful, and the first to yield. Corrections are versioned: when you change the picture, decisions made afterward reference the picture that was in force, which is what keeps [traces](/concepts/decisions-and-traces) honest over time. ## What memory holds * Audience behavior, and what precedes conversion. * Which messages and moves worked. * Your team's working patterns: what gets approved, changed, and rejected. * The resolved results of past decisions. A decision only becomes memory when its outcome is in. The system learns from what happened, not from what it hoped. You can also **pin facts** you want the system to always remember, and correct anything it has learned. Closed-loop, self-learning optimization over memory is a Team and Enterprise capability. ## Why it compounds Context makes the first decision possible. Memory makes the thousandth one better. Evidence earned in your workspace outranks generic benchmarks the moment it exists, which is why the system sharpens with use instead of going stale. See [The compounding loop](/measurement-and-outcomes/compounding-loop). # Decisions and traces The decision is the unit of work, and the trace is its receipt. What counts as a decision, and what a trace records. A **decision** is a moment where the system chose one option over others, spent something finite doing it, and said what it expected to happen. All three parts matter: * Choosing without spending is analysis. * Spending without stating an expectation is just activity. * The decision is the unit of work. Everything else is a step along the way. "Something finite" means anything there is a limited amount of and running out matters: credits, email sends, ad budget, a person's attention, a slot in a contact's outreach cadence, or room under your audience ceiling. ## Decision or step? The test is simple: **it is a decision if it spends capacity, claims a record, or changes what is under management.** Everything else is a step, real work, worth recording, but nothing was at stake in choosing it. | Example | Verdict | | ------------------------------------------------------------------ | ---------------------------------------------------------------- | | Enrich one record | A step | | Choose *which* 1,200 records to enrich, instead of the other 3,000 | A decision | | Run a query to build a list | A step. The *criteria* were the decision | | Import a list | A decision: it changes what you manage | | Activate an audience to a channel | A decision: it spends sends or budget, and claims those contacts | ## The trace is the receipt A decision is a specific, auditable action, reversible where the channel allows. It is never just a recommendation. Every decision writes a **trace** before it runs: * **Why** it was made, and on what evidence. * **Under what authority**: proposed, approved by you, or approved by a policy you set. * **For whom**, and what it expected to happen. * **What came back.** When the outcome arrives, it attaches to the same trace. Ask "why did we do that?" about anything, and the answer is on record. It was written before the action ran, never reconstructed afterward. ## The ordering One arc runs from a signal or a question to an outcome, and it contains several decisions along the way: choose the audience, choose the channel, choose the budget. Each decision can produce activations, and each activation its steps. The outcome attaches to the decision that caused it. ## Expected versus actual Every decision states what it expects: which number moves, by how much, by when, at what spend. The outcome arrives in the same shape, and a **learning is the subtraction**, actual minus expected, never an essay. That is what makes the system's judgment inspectable: where was it wrong, by how much, and in which direction. The most important question this makes answerable is the one no dashboard asks: **what did we decide and never find out about?** An unmeasured decision is worse than a wrong one. A wrong decision teaches something. An unmeasured one spent something real and taught nothing, so the system surfaces these rather than burying them. Where you read traces day to day is covered in [Traces and receipts](/measurement-and-outcomes/traces-and-receipts). # Data flow and trace spine The trace spine: five streams, one trace ID, and where your data lives. Everything the platform does travels five streams, in order, and every record on every stream carries the same trace ID. That spine is the whole trick: it is what lets a click, the decision it triggered, and the deal that closed be joined end to end. ![The trace spine: events to outcomes, joined by a shared trace ID](/files/o3sdyhR9WHFapHx4T1kn) 1. **Events**: raw happenings arrive, page views, form fills, CRM changes, channel activity. 2. **Identity**: each event is resolved to a real person and account, retroactively when needed. 3. **Signals**: resolved events become scored signals, the inputs to FIRE and to decisions. 4. **Decisions**: the system chooses, and writes its reasoning before acting. 5. **Outcomes**: what happened comes back and attaches to the decision that caused it. The forward leg plans and activates; the return leg measures and attributes. Nothing on the return leg is self-reported by a channel: outcomes join on the trace ID, not on a platform's claims. ## In and out Data enters through your connected sources: the pixel, your CRM, your warehouse, enrichment. It leaves as activations into your channels and, where configured, as syncs back to your warehouse. Consent and suppression flags travel with records the whole way, so an exclusion upstream is an exclusion everywhere downstream. ## Where it lives Managed by the platform by default, with your workspace isolated end to end. Enterprise deployments run the data plane against your own warehouse (Snowflake, BigQuery, Databricks, or Redshift), so the streams live where your data already does; our team sets up the connection with you. # Surfaces One engine, many doors: the app, Slack, email, and the agent-facing surfaces. There is one engine, and several doors into it. Wherever you meet the platform, it is the same iHarness, the same Growth Brain, and the same record. Acting in one place resolves everywhere. The doors: * **The web app**, **Slack**, and **email**, where your team already works. * **Inside Snowflake**, as a native app in your own account. * **The agent-facing surfaces**: CLI, API, MCP, and your own agents. Surfaces are an access layer, not a product. You do not move your team into a new tool. The platform shows up where they already work. ## The app The full working surface: Audience, Plays, Pulse, Measurement, Settings, with chat available on every screen. iHarness reads what you are looking at, so "suppress these" means the list in front of you. ## Slack One bot, **@iHarness**, the same identity you chat with in the app. Ask questions, receive pulses, and approve from the thread. A conversation started in Slack is the same conversation in the app. ## Email and the return path The daily digest arrives by mail, and lifecycle email brings you back when something deserves attention. Returning users land in [Pulse](/pulse/queue), where whatever needs them is already queued: that is the whole returning journey, by design. ## Your own agents The platform is built to be operated by agents as well as people, the same questions asked over a wire instead of a screen. Your agent connects through MCP as a custom connector, with a URL and a key. The procedure is in [Bring your own agent](/iharness/bring-your-own-agent). iHarness's own agents work on the inside, and they are predefined. Your agent connects in from the outside and works with the same context. CLI and API access: [join the waitlist](https://www.icustomer.ai/contact). ## Two journeys, every surface However many doors there are, there are only two journeys: the first-time journey (onboarding, ending at your first live play) and the returning journey (a reason to come back, already queued). After that, the loop orchestrates itself. # Worked example One arc, end to end: a cold account comes back, and the loop turns it into a meeting, with receipts. One arc, end to end. The numbers are illustrative; the mechanics are exactly what the platform does. {% stepper %} {% step %} ## A signal arrives An account your team closed-lost last year returns to your pricing page. * To an analytics tool: an anonymous session. * Here: an **event** entering the loop. {% endstep %} {% step %} ## It resolves Identity matching ties the visit to the account. * The visitor's earlier anonymous activity re-attributes to the same record. * The old opportunity, the past emails, the fit you already established: one story again. {% endstep %} {% step %} ## The score moves Pricing-page intent from a good-fit, previously engaged account moves Intent and Recency sharply. * The account flips **Hot**. * The reason is attached: not "score changed," but *which* signal moved it and why it matters. {% endstep %} {% step %} ## A decision is made iHarness diagnoses the moment: a win-back situation, not a cold outreach one. Before anything runs, it: * selects the play whose lever matches, * chooses the audience slice and the channel, * states what it expects to happen, * and writes the [trace](/concepts/decisions-and-traces). {% endstep %} {% step %} ## You approve The proposal arrives in [Pulse](/pulse/queue) as a stall waiting on your call: the account, the reasoning, the plan, one primary action. You approve; the gate opens. {% endstep %} {% step %} ## It activates The activation goes to your outbound channel, personalized against everything the context knows, inside the guardrails: * the contact is claimed by this one cadence, * suppression checked, * your CRM updated rather than overwritten. {% endstep %} {% step %} ## The outcome comes back A reply, a meeting booked. * The outcome joins on the trace ID. * It credits the decision that caused it, not the last click, not the loudest channel. {% endstep %} {% step %} ## The loop learns Expected versus actual is recorded. The next time a closed-lost account warms up, the diagnosis is sharper because this arc happened. That is the whole platform, once: signal, identity, score, decision, gate, activation, outcome, learning, one trace ID from start to finish. {% endstep %} {% endstepper %} # What iHarness does iHarness is the AI you talk to: it reasons over your context, decides what to do for each audience, and coordinates the agents. iHarness is the AI you work with. It says "I'm iHarness," and it is the only voice you deal with: it reads your [context](/concepts/context-and-memory), decides what to do for each audience, and puts the right [agent](/reference/agent-catalog) on the job, with no hand-offs for you to manage. It works two ways, all the time: * **When you ask.** Tell it what you want in plain language, in the app or in Slack. "Set up a reactivation play for dormant accounts." "Why did we pause LinkedIn last week?" * **On its own.** The loop runs over your audiences without prompting: it watches for signals, decides, and tells you what it did or what it needs from you. ## Decision-first iHarness decides *what* should happen before it decides *where*. Engage, nurture, suppress, or escalate comes first. The channel is the output of that decision, never the input, and that order is what keeps spend honest and measurement clean. ## It proposes, you dispose Anything that goes live, a play, a budget, a sequence, reaches you as a proposal first, and approvals land in [Pulse](/pulse/queue). Where you have granted autonomy, it acts within those bounds and shows its work. Where you have not, it waits at the [gate](/iharness/gates). ## It shows its work Every decision is recorded as a [trace](/concepts/decisions-and-traces): the signal, the reasoning, the authority, the action, and the outcome. Ask "why?" about anything and iHarness answers from the record, not from memory. ## What it holds * **Goals and targets.** Your objective function: pipeline, revenue. Goals are the input to the whole system, and without one nothing runs. What does it optimize for? Whatever you told it to. See [Goals, KPIs and targets](/iharness/goals-kpis-targets). * **Pulse.** The human channel: alerts, approvals, and your autopilot settings. What does it do without asking you? Whatever you have approved it to do. Everything else waits in [Pulse](/pulse/queue). * **Orchestration.** Runs plays through agents. Plays live here: they are the patterns Orchestration executes, not a separate product. ## What it runs on iHarness runs on your Growth Brain: it reasons over your [context and memory](/concepts/context-and-memory), chooses plays by [diagnosis](/iharness/plays-to-decisions), and paces your [goals and targets](/iharness/goals-kpis-targets). The better the context, the better every decision downstream. # Goals, KPIs and targets The chain iHarness optimizes: standing goals, readable KPIs, and computed, achievable targets. Three objects, one chain: **goal → KPI → target**. The goal says what you care about, the KPI says what can be read, and the target says what you are committing to. Outcomes move targets, and targets move KPIs; the whole chain is computed, not asserted. ## Goals A goal is one of six standing go-to-market ambitions. Goals never expire; you pick a primary focus, and the loop works it continuously. * **Pipeline Growth**: more qualified pipeline via outbound, inbound, and partner motions. * **Product-Led Growth**: self-serve adoption, activation, and in-product conversion. * **Retention & Expansion**: reduce churn, lift NRR, and drive upsell in existing accounts. * **Partner & Ecosystem**: channel and tech partnerships for scalable distribution. * **Brand & Community**: category authority through thought leadership and community. * **GTM Efficiency**: optimize CAC, sales velocity, and conversion across the funnel. {% hint style="info" %} You do not have to pick everything up front. Start with one target; the standing goal picture sharpens as the loop accumulates evidence. {% endhint %} ## KPIs A KPI is what the business can actually read. Measurability is definitional: if no connected source makes a number readable for your workspace, it is not a KPI there, and nothing will pretend otherwise. Each goal carries a primary KPI, the number it lives or dies on, plus supporting ones. A few executive numbers are deliberately never targets: ratios like Rule of 40 or marketing as a percent of revenue are context for leadership, not work items anyone can be paced against. ## Targets A target is not a number on a dashboard. It is an achievable work item, and achievability is computed, not hoped: * **A readable KPI.** No readable number, no commitment. * **At least one play that can move it.** A commitment with nothing behind it is a wish; a target always ships together with the plays serving it. * **A guardrail.** Every rate target carries a volume floor, so it cannot be "won" by shrinking the denominator. * **A leading indicator and a checkpoint.** What must move early if the plan is right, and when we look. * **A window that fits your sales cycle.** A 30-day window on a 90-day cycle cannot resolve, so it is not allowed. * **An owner and a deadline.** A target closes: met, missed, or abandoned. "At risk" is a computed flag along the way, not a status anyone sets. {% hint style="info" %} When the system cannot support a target honestly, it says so and names what would unlock it, rather than producing a confident number. Refusing to guess is the feature. {% endhint %} ## How the chain moves Outcomes land against decisions, decisions credit targets, and targets roll into their KPIs. When a target closes, what it proved becomes evidence for sizing the next one, which is how the bar moves as your business gets better. See [How plays become decisions](/iharness/plays-to-decisions) and [The compounding loop](/measurement-and-outcomes/compounding-loop). # Ask iHarness Talking to iHarness: ask it to do things, ask it questions, and brainstorm without spending anything. Chat is how you work with iHarness, in the app or in Slack, and it works three ways. ## Ask it to do things Say what you want in plain language: "build a list of Hot accounts that visited pricing this month," "set up a reactivation play for dormant accounts," "suppress everyone in this cohort from paid." iHarness plans the work, shows you the plan, and anything that commits spend or records waits at the [gate](/iharness/gates) for your confirmation. ## Ask it questions It answers from the record, not from vibes: "why did we pause LinkedIn last week?" reads the trace; "how is the target pacing?" reads the outcomes; "what changed in my audience this week?" reads the scores. If the honest answer is "that number is not readable from your connected sources," that is the answer you get. ## Brainstorm and simulate Think out loud safely. Sketch a play, weigh a budget split, explore "what would happen if", none of it commits anything. Simulation never spends: no credits drawn, no sends, no audience claimed. When a sketch is worth running, iHarness turns it into a real proposal and *then* asks for your approval. ## It knows where you are Chat is context-aware: on a list, "these" means that list; on an account, "this account" needs no explanation. Multi-select works too, pick twelve contacts and act on exactly those. {% hint style="info" %} One more habit worth forming: when a proposal arrives, ask "why this?" before approving. The reasoning is always on record, and reading it is how you calibrate how much [autonomy](/iharness/autonomy-levels) to extend. {% endhint %} # How plays become decisions How iHarness picks a play: diagnosis over lookup, capability before commitment, and decisions as the output. iHarness does not pick plays from a menu. It diagnoses. ## Every play pulls a lever A play is not just a description of work; it declares the **lever** it pulls, the mechanism by which it moves a KPI. Several plays can move the same number by different levers: one fills the top of the funnel, another accelerates what is already in it, a third stops waste. Naming the lever is what turns selection into a diagnosis instead of a lookup. ## Diagnosis, not lookup When a KPI is off, iHarness asks *why* before asking *what to run*: which cause is present, which signal detects it, and which play addresses that cause. Two workspaces with the same slow number can get different plays, because the cause differs. Where the system cannot diagnose, it says so plainly and falls back honestly, rather than dressing a guess as a diagnosis. ## Capability before commitment The order surprises people: the play portfolio is chosen **before** the target is finalized. iHarness sizes a target from what the serviceable plays can actually deliver, never from the benchmark alone. Nobody should be asked to commit to a number before being shown what could move it. ## Running a play produces decisions A play in motion is a stream of [decisions](/concepts/decisions-and-traces): which records are in scope, which get spend, which channel, which budget. Each one spends something finite, states what it expects, and writes its trace. That is the contract that makes a play accountable: not "it ran," but "here is what it chose, what it spent, and what came back." ## And outcomes come back around Outcomes credit the decisions that caused them, decisions credit the target, and what a closed target proves becomes evidence for choosing and sizing the next play. See [Goals, KPIs and targets](/iharness/goals-kpis-targets). # Autonomy levels The three autonomy modes, Ask, Propose, and Auto: defined by what the system can spend, not by a marketing scale. iHarness runs at one of three autonomy levels. The levels are not a mood setting; each one is defined by what the system is allowed to spend, credits, sends, budget, your audience's attention. ## The three modes | Mode | What it does | Spend | | ----------- | -------------------------------------------------------- | ------------------------------------------ | | **Ask** | Reads, diagnoses, explains. Proposes nothing unprompted. | Spend verbs are absent | | **Propose** | Raises cards, stages work, and waits for your click. | Present, but gated on your approval | | **Auto** | Completes an arc without a human. | Full, within caps and behind a kill switch | ## Absence is a stronger guarantee than a gate The distinction that matters most is between Ask and everything else. In Ask mode the ability to spend is not gated behind an approval; it is not there at all. A gate can be misconfigured; an absent capability cannot fire. That is why diagnosis and explanation are always safe to ask for, at any level. ## Where the levels meet your day **Propose** is where approvals live: staged work arrives as cards in [Pulse](/pulse/queue), and nothing moves until you click. **Auto** is bounded, not blind: caps limit what an arc can spend, the kill switch stops everything, and every decision still writes its [trace](/concepts/decisions-and-traces) before it runs. The per-tool controls that shape all three levels are covered in [Gates](/iharness/gates), and the practice of widening autonomy as judgment proves out is covered in [Autopilot vs approval-first](/pulse/autopilot-vs-approval-first). # Bring your own agent Bring your own agent: connect an external agent to iCustomer through MCP, with the same context and the same record as your team. The platform is built to be operated by agents as well as people. Your own agent connects through **MCP** (Model Context Protocol) and asks the same questions your team asks in the app, over a wire instead of a screen. ## What your agent gets * **The same context.** It reads the same Growth Brain your team works from, scoped to your workspace. * **The same record.** Anything it does lands in the same decision traces, under the same [gates](/iharness/gates). An external agent never gets more authority than the person who connected it. * **The same guardrails.** Suppression, consent, and the one-cadence-per-contact rule apply to agents exactly as they apply to plays. ## Connecting iCustomer connects as a custom connector, the standard way any remote MCP server is added to an agent. {% stepper %} {% step %} ### Open your agent's connector settings In Claude, open [Add custom connector](https://claude.ai/new?redirect=claude.com\&modal=add-custom-connector#settings/customize-connectors). Other agents have the same option under their MCP or connector settings. {% endstep %} {% step %} ### Add iCustomer Name: **iCustomer**. Remote MCP server URL: `https://mcp.icustomer.ai/mcp`. {% endstep %} {% step %} ### Connect Select **Connect** and sign in with your iCustomer account. That authorizes your agent for your workspace. {% endstep %} {% step %} ### Ask away Your agent now works with your Growth Brain. Try: "Who went Hot this week, and why?" {% endstep %} {% endstepper %} ## Your agent and iHarness's agents iHarness runs its own agents on the inside. They are predefined, and you do not create or curate them. Your own agent connects in from the outside through MCP and works with the same context. See [Surfaces](/concepts/surfaces). # Gates The checkpoints that stop iHarness: what gates guard, where approvals happen, and per-tool approval modes. A gate is the checkpoint between a proposal and the real world. iHarness can think, plan, and draft freely; the moment an action would commit something, budget, sends, credits, a change to your CRM, it stops at the gate and waits for a human. ## What gates guard Gates sit exactly where spend and consequence sit: activating a play, pushing an audience to a channel, writing to CRM records, committing budget. Reading, scoring, and drafting never need a gate, which is why the system can be always-on without being dangerous. ## One approval, anywhere An approval request reaches you where you are: in [Pulse](/pulse/queue), in chat, in Slack. It is the same request in every surface, and approving in one place resolves it everywhere. The approval itself, who, when, for what, is recorded on the decision's [trace](/concepts/decisions-and-traces). ## Per-tool approval modes Gates are tunable per tool, three modes: * **Always allow**: the action runs without asking. For reads and low-stakes writes you trust. * **Needs approval**: the default for anything that writes. The action waits for you. * **Blocked**: the action is off entirely. Writes default to needs-approval. As trust builds, you widen specific gates deliberately, which is the practical mechanics behind [Autopilot vs approval-first](/pulse/autopilot-vs-approval-first). ## Gates are not friction A gate fires once per commitment, not once per step. Approve a play and it runs, within its bounds, without re-asking on every send. The design goal is a system that asks rarely, asks clearly, and never acts beyond what you granted. # The queue Pulse is the attention layer: only what needs a human, everything else handled in the background. Pulse is your attention layer: only what needs a human. The system works continuously in the background. When something needs you to see it or decide it, it raises a hand here, and the rest is reported in your [daily digest](/pulse/daily-digest). What does it do without asking me? Whatever you have approved it to do. Everything else waits here. Pulse is a communication channel, not a dashboard. The heart of the surface is **Needs you**: the queue of pulses with a pending action. The badge counts exactly those, so **badge zero means nothing is waiting on you**, not "nothing happened." Clear the queue and you are caught up. ## Push and pull Pulse is the push side of the platform. | | Who starts it | What it looks like | | -------- | ------------- | -------------------------------------------------------------------------------------------------------- | | **Pull** | You | You run a play. | | **Push** | The system | It raises its hand. An opportunity worth acting on arrives as a pulse, and running it remains your call. | ## What arrives Every pulse has three parts: * one [family](/pulse/families), * a severity tier, * and one primary action, leading. A pulse is generated at the moment it fires, from what the system actually observed, with one line of reasoning attached. Pre-written sequences are lifecycle email, not pulses. ## The tabs are views Tabs like Activation, Digest, Alert, Inbound, Setup, and Insight are lenses computed from each item's metadata, never hand-sorted piles. * **Needs you** is the default. * **Activation** is a status board for what is currently live. * **Digest** holds your daily envelopes. Acting on a pulse (approve, modify, reject, or skip) is covered in [Acting on a pulse](/pulse/acting). Where pulses reach you is covered in [Delivery](/pulse/delivery). # Families The three pulse families: Opportunity, Stall, and Milestone, and what each one asks of you. Every pulse is stamped with exactly one family, and the family tells you at a glance why the moment matters: * **Opportunity** asks you to act on something good, before the window closes. * **Stall** means an edge of the loop cannot advance, and the pulse brings the reason and the remedy with it. Work waiting on your call is a stall whose remedy is your click; something going wrong is a stall with its root cause attached. * **Milestone** marks a first worth seeing. No action needed; worth ten seconds. Every stall names the [loop edge](/getting-started/the-loop) it fired from, so the pulse never just says "blocked": it says which step, what is in the way, and what would clear it. The full catalog, with the five stall edges and examples per family, lives in [Pulse families](/reference/pulse-families) in Reference. ## Families in the app In the app, the queue is also sorted by tabs: **Needs you**, **Activation**, **Digest**, **Setup**, **Alert**, **Inbound**, and **Insight**. Tabs group items by what they are and where they came from; the family says why a pulse matters. One pulse carries both, so a failed sync sits in the Alert tab as a Stall, and a hot reply sits in Inbound as an Opportunity. ## How families shape behavior Families and severity tiers are the queue's two filters. A pulse's family also sets expectations for its mode: a **decide** pulse carries a pending action and can interrupt; an **inform** pulse never interrupts, it folds into the [daily digest](/pulse/daily-digest) and is measured by whether it was worth reading. Families are stamped by the system, never hand-assigned, so filtering by family always means the same thing, in the app, in email, and in Slack. Per-family delivery preferences are covered in [Delivery](/pulse/delivery); acting on a pulse is covered in [Acting on a pulse](/pulse/acting). # Acting on a pulse The four things you can do with a pulse: approve, modify, reject, or skip. Every pulse that needs you leads with one primary action, and you have four moves. * **Approve.** The proposed action runs as presented. The approval is stamped on the decision's trace: who, when, what was approved. * **Modify.** Right idea, wrong detail. Adjust the proposal, a smaller audience, a different channel, a lower budget, and the updated version comes back for a clean approval. You are never editing a live action, only its proposal. * **Reject.** Not this, and the system should know it. A rejection is recorded and learned from: rejected proposals shape what gets proposed next. * **Skip.** Not now. The pulse leaves your queue without a verdict; the underlying situation is not deleted, and if it still matters later, it comes back with fresh evidence. ## What acting does Acting anywhere resolves everywhere: approve in Slack and the app agrees. Every resolution is terminal and recorded, so the queue only ever shows things that genuinely still need you. Clearing it means you are caught up, not that you dismissed things into the void. {% hint style="info" %} The reasoning is one tap away on every pulse. Reading it before approving is cheap; approving what you have not read is how autopilot gets a bad name. {% endhint %} # Autopilot vs approval-first The autonomy dial: approval-first by default, autopilot where you have deliberately opened it. {% columns %} {% column %} ### Approval-first The platform starts with a simple posture: **approval-first, everywhere.** Nothing commits spend, sends, or record changes without a human saying yes. That is not a training-wheels mode; it is the default contract. {% endcolumn %} {% column %} ### Autopilot **Autopilot** is not a switch, it is a dial you open deliberately, per tool and per kind of action, using the [gate modes](/iharness/gates): move a specific action from needs-approval to always-allow, and iHarness handles that class of work without asking, while still recording every decision as if it had asked. {% endcolumn %} {% endcolumns %} ## How trust is supposed to build {% stepper %} {% step %} ### Start approval-first Read the reasoning on proposals; approve, modify, reject. {% endstep %} {% step %} ### Notice what you always approve When a class of action has earned a streak of unedited approvals, that is the candidate. {% endstep %} {% step %} ### Open that gate, narrowly One tool, one action type. Not "autopilot everything." {% endstep %} {% step %} ### Audit by trace, not by trust Autonomous decisions carry the same receipts as approved ones; the reasoning stays inspectable whether or not you were asked. {% endstep %} {% endstepper %} ## What autopilot never overrides Suppression lists, consent, caps, and the one-cadence-per-contact rule bind autonomous actions exactly as they bind approved ones. And the whole dial closes instantly: return any gate to needs-approval, or blocked, at any time. {% hint style="info" %} Practical recommendation: run approval-first for your first weeks. The approvals are how you calibrate the system, and how it calibrates to you. {% endhint %} # Delivery Where pulses reach you: always in-app, and by email or Slack where you opt in. Pulses always land in the app; that is the record, and it cannot be turned off. Email and Slack are opt-in, per user, with preferences you control per family, so one person can get Stalls in Slack while another only reads the digest. ## The interrupt discipline Only the most urgent tier stands alone in email or Slack. Everything else rides the daily rollup, marked "already alerted" if it reached you earlier, so your inbox gets one envelope a day, not a drip. The interrupt cap keeps standalone pings rare; when more qualify than the cap allows, the rest demote into the digest rather than being dropped. ## Slack Slack delivery comes through one bot, **@iHarness**, the same identity you chat with. A pulse in Slack carries the same primary action as in-app; acting in either place resolves it everywhere. ## What delivery never does Delivery preferences change where a pulse reaches you, never whether it exists. Every pulse is on the record in the app regardless of channel, and the [daily digest](/pulse/daily-digest) accounts for everything the system did, alerted or not. Lifecycle email, onboarding nudges and scheduled sequences, is configured separately and is not part of Pulse delivery. # Daily digest One envelope a day: what the system did, what needs you, and what is ahead. The digest is the daily account of the loop: one envelope, once a day, covering what the system did, what already reached you, and what is coming. It is part of Pulse, not a separate surface, the same record, rolled up. ## What is in it * **What ran**: the plays, activations, and notable decisions of the day. * **What reached you already**: anything that pulsed earlier appears marked "already alerted," so the digest never double-pings you. * **What is worth knowing**: inform-mode pulses, the interesting-but-not-urgent, live here rather than interrupting you. * **What is ahead**: scheduled runs and checkpoints approaching. ## The discipline behind it The digest exists so interruptions can be rare. Only the urgent tier stands alone in email or Slack; everything else waits for the envelope. If your day was quiet, the digest is short, it reports what happened, it does not perform activity. ## It talks back The digest is a door into chat: reply to any line, "why did this play pause?", "expand on the audience shift", and you are in a conversation with iHarness with that item's context loaded. Delivery, when and where the envelope arrives, is configured per user; see [Delivery](/pulse/delivery). # Identity One person, one record: how identities resolve, and the rules that keep your CRM safe. One person is one record, and one company is one account, no matter how many fragments arrive: a form fill here, a CRM row there, an anonymous visit last month. Identity resolution is what makes those the same story, and it is the reason outcomes can ever credit the decisions that caused them. ## How identities resolve * **A verified match earns an immutable ID.** When the system confirms who someone is, that identity is fixed. Everything after attaches to it. * **That ID is a OneSource ID.** It is the identity foundation the Growth Brain is built on. Licensed third-party data enters only by resolving to it, and is never written raw into your systems. * **Everything else is an alias.** Additional emails, a CRM ID, a phone number, an enrichment ID: aliases on the one record, not new records. * **Resolution is retroactive.** When an anonymous visitor becomes known, their earlier activity is re-attributed to the same identity, so history is never lost to timing. Your CRM stays the system of record. Where permitted, the platform writes its ID back into your CRM so both systems can always find the same person. ## The rules that protect your CRM * **The platform never deletes a CRM record.** Ever. * **It never auto-merges.** When it finds likely duplicates, it proposes the merge as a pulse, with the evidence. You approve, and only then does it execute, with the decision recorded. CRM merges are irreversible in most CRMs, which is exactly why a human holds the pen. * **It updates rather than overwrites**, and never touches sales-owned fields. ## Where identity comes from Signals flow in from [the pixel](/integrations/events-and-pixels) (form emails, reverse-IP company resolution), your [CRM sync](https://github.com/colby-iCustomer/audience-loop-user-guide-public/tree/main/integrations/crm-sync.md), and enrichment. Conflicts resolve by trust: what you have declared outranks your CRM, which outranks inferred sources. Identity is the foundation [FIRE scoring](/audience/fire-scoring) and every decision stand on. # Signals The events that move scores and trigger decisions, and where they come from. A signal is an event that tells the system something changed about an account or a person, the raw material every score and decision is made from. ## What counts as a signal * **What they do on your surfaces**: site visits, pricing-page views, form fills, demo requests, email opens and replies. * **What changes at the company**: hiring for the problem you solve, new leadership, funding, adopting a tool you integrate with. * **What your systems say**: CRM stage changes, deal activity, product events where connected. ## Where signals come from First-party first: [the pixel](/integrations/events-and-pixels) and your connected tools carry the highest trust, because they are observed, not reported. Enrichment and intent sources add the outside view. When sources conflict, trust order decides; see [Context and memory](/concepts/context-and-memory). ## Two properties that matter * **Signals attach to identities, not sessions.** A signal is only useful once it belongs to a resolved person or account, which is why [identity](/audience/identity) and clean domains come first. An event that cannot resolve waits; it is not guessed onto someone. * **Signals age.** A pricing visit last week is not one from last quarter. Freshness is built into scoring through Recency, so the picture decays honestly instead of accumulating forever. ## What signals do They move [FIRE scores](/audience/fire-scoring), they trigger pulses when a moment needs a human, and they start plays whose conditions they meet. A strong single signal, a demo request, say, can flip an account Hot and set the loop in motion within the moment it happens. {% hint style="info" %} How fresh signals arrive follows your plan: daily-batched on Pro, live stream on Team and above. {% endhint %} # Building and sharing audiences Cohorts under segments: how audiences are built, shared, and made activation-ready. Audiences are organized simply: two **segments**, B2B and D2C, and under each, **cohorts**, named groups defined by shared traits, scores, or behavior. A cohort is the working unit: what you watch, share, and activate. ## Ways to build * **Ask iHarness.** The fastest path: "accounts that visited pricing in the last 30 days and score Hot." The cohort arrives with its logic attached and stays live as members qualify in and out. * **Hot lists.** Auto-maintained cohorts the system keeps for you, your hottest accounts, your resolved recent visitors, so the obvious lists never need building. * **Import.** Bring a list from CSV, Sheets, or your CRM. Imported records join identity resolution like everything else, so duplicates collapse instead of multiplying. * **From the loop.** Plays produce cohorts too: everyone a play touched, everyone who converted, everyone suppressed. ## Sharing Cohorts are workspace objects: your team sees the same audiences, with the same membership and scores, governed by [roles](/settings/users-and-roles). One shared definition beats five private spreadsheets that almost agree. ## Activation-ready means something A cohort can be *activated* when its members carry what the destination needs: the right identifier (email for outbound; hashed identifiers for ad platforms) and the right consent. The platform checks this per destination and reports **matched** counts honestly, what the channel accepted, not what you uploaded. Suppressed records are excluded before anything leaves. ## What you get back A built cohort returns four things: * a **live membership**, resolved through identity so one person is one record, * a **FIRE score** on every member, with the reason attached, * an **activation-readiness read** per destination: matched counts, missing identifiers, consent gaps, * and a **shared workspace object** your whole team sees identically. Audiences do not sit still after building; the system keeps watching them. See [Always-on monitoring](/audience/monitoring). # FIRE scoring How every account and contact is scored: Fit, Intent, Recency, and Engagement, rolled into Hot, Warm, or Cold. Every account and contact under management carries a FIRE score, so you always know who is worth acting on right now, and why. ## The four components | Component | The question | What moves it | | -------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | | **Fit** | Is this the right kind of company or person? | Your ideal customer profile, firmographics, role, and the commercial traits you confirmed in your context. | | **Intent** | Are they showing buying signals now? | Pricing-page visits, demo requests, hiring for the problem you solve. Weighted by strength, and capped so one noisy source cannot dominate. | | **Recency** | How fresh is what we know? | Signals decay. Last quarter's interest is not this week's. | | **Engagement** | Have they interacted with *you*? | Opens, clicks, replies, visits: the history of the relationship. | Fit anchors everything: a perfect-intent account that is a terrible fit is still a terrible fit. Fit is set by your context. Intent, Recency, and Engagement move on their own as signals arrive. ## Hot, Warm, Cold The components roll into one tier: **Hot** (act now), **Warm** (worth working), **Cold** (watch, or suppress from spend). A single strong signal can flip a tier, a demo request lifts Intent and can turn an account Hot in the moment it happens, which is exactly when the loop reacts. ## The reason comes attached A score is never a bare number. Each scored record carries its reasoning: which signals moved it, and why. * When a play selects "the top 500 by FIRE," you can open any of them and see the case. * Scores update continuously across your [audiences under management](/audience/building-audiences). * Scores are what plays target and what [decisions](/concepts/decisions-and-traces) cite. # Always-on monitoring What under management means: continuous scoring, cohort-shift detection, and a hand raised when something moves. "Under management" is a promise: the accounts and contacts in the audiences you have under management are watched continuously, not scored once and left to rot. ## What the system watches * **Scores, continuously.** FIRE components update as signals arrive and as recency decays, so Hot means hot *now*. * **Cohort shifts.** Membership changes are tracked over time: a cohort quietly shrinking, a surge of new qualifiers, a segment cooling. Snapshots make the drift visible instead of anecdotal. * **The picture's own health.** Identities that resolved, records that went stale, coverage that dropped. ## When it raises a hand Monitoring feeds [Pulse](/pulse/queue), not a dashboard you have to remember to check. A meaningful shift arrives as a pulse with the reason attached. The routine picture waits for the [digest](/pulse/daily-digest), and quiet weeks are reported as quiet. ## What is managed, and what it costs Not everything you have ever imported needs managing. | | Counts against your plan? | | ---------------------------------------------------------- | -------------------------------------------- | | Everything you have brought in | No. It is free to hold. | | The actively monitored set, the audiences under management | Yes. This is what your plan capacity covers. | | Sending to a static list | No. It does not put anyone under management. | Billing follows engagement, not blast volume. Plan capacities are in [Plans](/getting-started/plans). # What a play is Play, run, activation: the three words, and how a motion actually executes. Three words, one chain: **Play → runs → activations.** * A **play** is a named, proven motion, "Convert Anonymous Traffic," "Find More Like Your Best Customers", with what it does and what it needs. Plays live in the [library](/reference/play-library); selecting one opens a chat where iHarness makes it yours: your audience, your channels, your goal. The play stays editable through that same chat: swap Instantly for a different sender, retarget it, tune it. * A **run** is one execution of the play. Scheduled plays run on their cadence; each run is ledgered. * An **activation** is what a run delivers into a destination: the audience pushed to LinkedIn, the sequence started in Instantly, the list synced to your CRM. One play can hold several activations, and each contact's activation history is tracked individually. You run a play, it leaves behind activations, and when those activations need you, they raise a hand in [Pulse](/pulse/queue). ## Plays are how automation happens Anything scheduled or recurring is a play; a one-time export is just an export. Buyer-facing automation lives here; internal alerts live in Pulse. That split keeps one place to look for "what is running against my audience." ## Nothing activates itself Creating a play never spends money on its own. Activation, committing budget, sends, and credits, always requires your explicit confirmation. After that, the play works within your [guardrails](/plays/guardrails-and-suppression), including the platform-wide rule that one contact is in at most one active cadence at a time. ## And every play accounts for itself A running play produces [decisions](/concepts/decisions-and-traces), each with its spend and its expectation on record. Browse what exists in the [Play library](/reference/play-library); set one up in [Setting up a play](/plays/setup). # B2B library The curated B2B plays, grouped by goal The launch library is eleven plays, grouped by the goal they move: pipeline growth, product-led growth, retention and expansion, brand and community, and GTM efficiency. Each play is picked from the library, made yours for your workspace, and editable through the chat where it was created. The full catalog, every play, what it does, and what it needs, is the [Play library](/reference/play-library). How a play runs and what it may never touch are covered in [What a play is](/plays/what-is-a-play) and [Guardrails and suppression](/plays/guardrails-and-suppression). # Setting up a play From the library to live: picking a play, reviewing the spec, and confirming activation. Setting up a play is a conversation, not a form. {% stepper %} {% step %} ### Pick a play Browse the [library](/plays/library-b2b) and choose the motion. Each card says what it does, what it needs, and what good looks like. {% endstep %} {% step %} ### iHarness instantiates it A chat opens, and the template becomes *your* play: your audience slice, your connected channels, your goal. If something it needs is missing, a connector, an identifier, consent coverage, it says so now, not mid-run. {% endstep %} {% step %} ### Review the spec One card: who it will touch, through what, on what cadence, spending what. The per-action rates behind that number, and a worked example of what a play run draws, are on [Billing](/settings/billing). Adjust anything in the chat, a different cohort, a swapped channel, a lower cap. {% endstep %} {% step %} ### Confirm to activate Activation is the [gate](/iharness/gates): budget, sends, and audience claims commit only on your explicit confirmation. Until then, nothing has been spent. {% endstep %} {% step %} ### Watch it run The play shows its runs: when it fired, what each run delivered, into which [activations](/plays/what-is-a-play). Anything needing you raises a hand in Pulse. {% endstep %} {% endstepper %} ## What you get back An activated play returns four things, continuously: * **runs**: each firing, with when and why it fired, * **activations**: what each run delivered, into which destination, * **decision traces**: the receipt behind every choice the play made, readable before and after it runs, * and **pulses** whenever something needs you: an approval, a problem, a first worth seeing. Nothing else arrives unannounced: if the play is quiet, nothing crossed its bar. Ask [iHarness](/iharness/ask-iharness) why; that is always the shortest path to the answer. ## Editing later The chat that created a play stays its control room. Reopen it to retune, retarget, swap a destination, pause, or stop, the play's history rides along, so changes are made in context. Every play runs inside the platform rules; read them once in [Guardrails and suppression](/plays/guardrails-and-suppression). # Guardrails and suppression The platform rules every play inherits: one cadence per contact, suppression above everything, honest counts, and a kill switch. Every play inherits the same platform rules. None of them are per-play options to remember; they are the floor. ## One active cadence per contact A person is in at most one active outreach cadence at a time, across all plays. When two plays want the same contact, priority arbitration decides and the other play waits, so nobody gets three sequences from three motions in the same week. This is enforced at the platform, not promised by configuration. ## Suppression overrides everything Your suppression list is absolute: it beats play logic, autonomy grants, and enthusiasm. Suppressed records are excluded before anything reaches a destination, and suppression flags travel with your data into every channel. Existing customers, opted-out contacts, do-not-touch accounts, once suppressed, no play argues. ## Consent and scope A record goes to a channel only with the identifier *and* the consent that channel requires: email consent for outbound, platform-appropriate hashed identifiers for ads. No consent, no send, silently and every time. ## Your CRM is protected Plays update records; they never overwrite sales-owned fields, never reassign ownership (they alert, you route), and never delete. Merges and other irreversible moves surface as proposals for a human. See [Identity](/audience/identity). ## Honest counts Match rates are reported as **matched**, what the destination actually accepted, never as uploaded. If a channel matched 60 percent of a cohort, you see 60 percent. ## Caps and the stop Spend and volume caps bound every play, and pausing or stopping is immediate, from the play, from chat, from a pulse. Stopping a play never deletes its history: the runs, decisions, and outcomes stay on the record. # Traces and receipts Where you read the receipts: what a trace shows for every activation decision. Measurement is where the receipts live. Every activation decision, why a list was activated, how its audience was chosen, under what authority, writes a [trace](/concepts/decisions-and-traces) before it runs, and Measurement is where you read them. ## What a receipt shows Open a trace and you see the whole arc in one place: * **What the system saw**: the signals and scores in force at the moment of the decision. * **What it chose, and why**: the option taken, the evidence, and the reasoning, written at decision time, not reconstructed later. * **Under what authority**: proposed and approved by a person (named), or autonomous within bounds you granted. * **What it did**: the activation and the channel it went to. * **What came back**: the outcome, attached to the same trace ID that started the arc. Because the click, the decision, and the closed deal share one trace ID, any result can be followed back to the exact reasoning that caused it. No black box, and no channel grading its own homework. ## Two feeds, reconciled Measurement reads two feeds and reconciles them: * **Channel analytics**, from every activation tool (ESP, LinkedIn, Meta, Trade Desk, Google), arriving through iConnect. What each platform says happened. * **iReveal**: visitor identity, outcomes, and causal proof, tied to real identities. What actually happened. Platform-reported numbers alone are not proof. The reconciliation is the point: causal proof, not last-touch attribution. ## Where receipts surface Reasoning shows up where you already are: on a contact or account's drawer, on draft cards, and in your digest. Scoped summaries appear inline, and the full trace sits behind them. ## The scope, honestly Traces are recorded for **activation decisions**: the moments where the system commits spend, sends, or audience membership. Finer-grained tracing of every internal step is on the roadmap, not the record today. What is traced is complete. What is not traced is not claimed. # Decision quality A different question than did it work: was the judgment good, measured as expected versus actual. "Did the outcome happen?" and "was the decision good?" are different questions. A good decision can lose to bad luck; a bad one can win by accident. Decision quality is the discipline of grading the judgment itself, and it is only possible because every decision states, up front, what it expects. ## Expected versus actual Each decision carries a typed expectation: which number moves, by how much, by when, at what spend. The outcome arrives in the same shape, and the difference is the grade. Aggregated over time, the grades answer questions no channel dashboard can: * Where is the system systematically over-confident, or under-confident? * Which kinds of decisions, which channels, which cohorts, which plays, does it judge well, and where is it still guessing? * What did we spend, grouped by what we were trying to do? ## The unmeasured decision The worst grade is no grade. A wrong decision teaches something; an unmeasured one spent something real and taught nothing. Decisions whose expected-by date passed with no outcome recorded are surfaced as their own list, not buried, because "we never found out" is a finding. ## Why this matters to you Decision quality is the honest basis for [autonomy](/pulse/autopilot-vs-approval-first): you widen the gates where the judgment is measurably good, and keep approvals where it is not. Trust built on grades beats trust built on demos. # The compounding loop The slower loop underneath: outcomes become evidence, evidence sizes the next commitment, and the bar moves with you. The loop you watch daily runs in weeks: signal to decision to outcome. Underneath it runs the **meta loop**, a slower loop that never closes, and it is the reason the platform is worth keeping after the first win. This page follows it through measurement. ## Outcomes become evidence When a target closes, what it proved, what a play actually moved, at what cost, in your market, is recorded as evidence. The platform is built so that **your own measured results outrank generic benchmarks the moment they exist**. Early on, targets are sized from reference data; the design is that each closed target replaces borrowed numbers with earned ones. ## The bar moves Because sizing draws on your evidence, the next target reflects what your business just showed it can do. Improve, and the system asks more; hit a ceiling, and the diagnosis points at the constraint instead of recycling the same ask. A static tool goes quiet after the first win; a compounding one gets more specific. ## What compounds, concretely * **Play choice**: which levers actually move your numbers, not the market's average numbers. * **Sizing**: commitments grounded in your measured effects. * **Judgment**: [decision quality](/measurement-and-outcomes/decision-quality) grades accumulate, sharpening where the system trusts itself and where it defers to you. * **Context**: everything above feeds [memory](/concepts/context-and-memory), so the thousandth decision starts smarter than the first. The daily loop wins you this quarter. The compounding loop is why next quarter starts ahead of this one. # Your stack How iCustomer Platform connects to the rest of your stack: connector categories, the connect flow, sync settings, and the recommended setup order. **iConnect** is the integrations layer, and the only part of the platform that touches your systems. It works in both directions: * **Activation out**: decisions land in your channels and your CRM. * **Governed connection in**: your data is read where it lives, never copied to run the platform. On Enterprise the connection is in place, in your cloud or warehouse, and nothing leaves except governed, approved activations. On SMB it connects to our managed cloud. Every connector is managed in one place: **Settings → Integrations**. ## Connector categories | Category | Direction | Examples | | --------------------- | -------------------- | --------------------------------------------------------------------------------------------------------------------------------------- | | CRM | Bidirectional | Salesforce, HubSpot ([CRM sync](https://github.com/colby-iCustomer/audience-loop-user-guide-public/tree/main/integrations/crm-sync.md)) | | Data warehouse | Inbound + write-back | Snowflake, BigQuery, Databricks, Redshift | | Ad platforms | Outbound | LinkedIn, Meta, Google, Reddit | | Email and outbound | Outbound | Instantly, Smartlead, Klaviyo | | Events | Inbound | Pixel, product events | | Enrichment and intent | Inbound | OneSource | | Notifications | Outbound | Slack, email | Per-platform overviews live on our site: [Connections](https://www.icustomer.ai/connections). Warehouse connections (Snowflake, BigQuery, Databricks, Redshift) are set up with our team. Enrichment is different from the rest of the table. It is 50+ data vendors behind one connection, one contract, and one credit meter, ours. Their data is resolved to OneSource IDs before it reaches your audiences, and it is never written raw into your CRM or media accounts. ## Connecting a tool {% stepper %} {% step %} ### Add Go to **Settings → Integrations**, choose the platform, and select Connect. {% endstep %} {% step %} ### Authenticate Most connectors use OAuth: sign in to the platform and authorize access. API-key connectors ask for the key instead. {% endstep %} {% step %} ### Configure Set the sync direction, frequency (real-time, hourly, or daily), and field mappings. Filters limit what syncs. {% endstep %} {% step %} ### Activate The platform verifies authentication and permissions when you save. Once the check passes, toggle the connector active. {% endstep %} {% endstepper %} A connector shows one of four states: **Connected** (active and syncing), **Paused** (configured, not syncing), **Error** (usually credentials), or **Not configured**. Removing a connector stops its syncs but does not delete data that already synced. ## When a connection misbehaves | Symptom | Likely cause | Fix | | ------------------------ | ---------------------------- | --------------------------------------------------------------------- | | Invalid credentials | Expired OAuth or wrong key | Re-authenticate | | Insufficient permissions | Missing scopes | Check the platform's permissions | | Rate limited | Too many requests | Reduce sync frequency | | Low match rate | Thin email or phone coverage | Improve identifier coverage | | Audience not updating | Sync paused or failed | Check sync status in [Data health](/setup-and-onboarding/data-health) | ## What you get back A connected tool returns three things: * a **status** you can trust (active, pending, expired, revoked, or error), surfaced here and raised in Pulse on failure, * its **data flowing into identity resolution**, sharpening scores and unlocking the KPIs and plays that need it, * and a **destination** the loop can act into, within your guardrails. If a connection is quiet or a sync looks stale, ask [iHarness](/iharness/ask-iharness) why. That is always the shortest path to the answer. ## Outside the app Connectors can be managed outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Events and pixels Install the pixel, what it captures, how visitors resolve to real accounts, and how consent works. The pixel is how the platform sees your site: who visits, what they look at, and which campaigns brought them. It is available on every plan, and it is the first-party signal that feeds identity, scoring, and attribution. ## Install the pixel {% stepper %} {% step %} ### Copy your snippet Go to **Settings → Visitor Intelligence** and copy your workspace's snippet. It is one small async script tag carrying your workspace id. {% endstep %} {% step %} ### Add it to your site Paste it into your site's ``, or add it through your tag manager. One snippet covers every page. A static-tag variant is available for sites with strict content-security policies. {% endstep %} {% step %} ### Confirm traffic Back in Visitor Intelligence, confirm the pixel is receiving traffic. That's it. {% endstep %} {% endstepper %} ## What it captures Page views (including single-page-app navigation), referrers, UTM parameters, scroll depth, and device basics. Form submissions are detected so a visitor who fills in an email becomes known. Your own site can also call `window.aloop.identify()` and `window.aloop.track()` for custom events (the tracker keeps its original `aloop` namespace; it is the same platform). ## How visitors become accounts Anonymous visits resolve to real people and companies two ways: a form email ties the visitor to a contact, and reverse-IP resolution ties the visit to a company. Resolution is retroactive: once a visitor resolves, their earlier anonymous activity is re-attributed to the same identity. {% hint style="info" %} Visitor resolution draws credits only when a resolve succeeds; per-action rates are in [Billing](/settings/billing). The pixel is available on all plans, and seeing visitors by name is included on all plans, Free included. {% endhint %} ## What you get back Once the pixel is live, each resolved visit returns four things: * the **account** (and, where a form ties it, the person), resolved to its immutable ID, * the visitor's **full activity**, including earlier anonymous sessions re-attributed to the same identity, * a **FIRE score movement** where the visit carries intent, with the reason attached, * and the **credits drawn**, charged only because the resolve succeeded. Resolved accounts appear in [Audience](/audience/building-audiences) under **Hot lists**, the system-built lists, as **Identified visitors**. Visits that do not resolve cost nothing and stay counted as anonymous traffic. ## Consent The pixel does not decide consent; your consent banner does. Wire the snippet into your consent management platform so the pixel loads only after the visitor consents, the same way you gate any analytics tag. If you use HubSpot's or another CMP's banner, load the pixel in the consent-granted callback. Consent and suppression flags then flow through everything downstream; see the [Security model](/security-and-compliance/security-model). ## Outside the app Visitor events can be viewed outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Destinations vs live channels The two ways data moves: live channels that act in real time, and destinations that sync in batches. {% hint style="info" %} **For warehouse workspaces.** {% endhint %} Data leaves the platform two ways, and the difference is simple. **A live channel acts the moment a decision happens. A destination receives batches on a schedule.** {% columns %} {% column %} ## Live channels Live channels are the tools the system acts into in real time: * your CRM (HubSpot or Salesforce), * ad platforms (LinkedIn, Meta), * outbound (Instantly). When a play decides to act, the action executes synchronously: a contact is routed, an audience is pushed, a sequence starts. The result comes back into the trace immediately. {% endcolumn %} {% column %} ## Destinations Destinations are batch pipelines: scheduled syncs that move data in bulk. * Into the platform from your sources, or out to your warehouse. * Each pipeline has a schedule and a job history (rows, duration, status). * Any pipeline can be triggered on demand. Use destinations for data movement. Use live channels for action. {% endcolumn %} {% endcolumns %} ## Connection health Every connection reports a status: **active**, **pending**, **expired** (re-consent needed, select Reconnect), **revoked**, or **error**. Statuses surface in [Your stack](/integrations/stack), and failures raise a hand in Pulse rather than failing silently. {% hint style="warning" %} A workspace connects one CRM, HubSpot or Salesforce, not both. Pick the system of record. The platform writes back to it and never overwrites sales-owned fields. {% endhint %} ## Outside the app Pipelines and channel actions can be managed outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Required tables The three core tables iCustomer Platform reads from your warehouse: Accounts, Contacts, and Events, plus the optional tables that enhance scoring and outcome tracking. {% hint style="info" %} **For warehouse workspaces.** {% endhint %} The platform runs on three core data entities. Everything else is optional. | Table | Required | Purpose | | -------- | -------- | ----------------------------------------- | | Accounts | Yes | The companies you target | | Contacts | Yes | The people at those companies | | Events | Yes | The behavioral signals that drive scoring | Optional tables that make the system sharper: | Table | Required | Purpose | | ---------------- | -------- | ---------------------------------- | | Opportunities | Optional | Pipeline data for outcome tracking | | Products | Optional | Product-usage signals | | Website Sessions | Optional | Anonymous visitor tracking | ## The minimum each table needs * **Accounts**: `account_id` (unique), `name`, and `domain`. The domain is the matching key, so it matters most. * **Contacts**: `contact_id` (unique), `account_id` (the link to the company), and `email`. Email drives identity matching. * **Events**: `event_id` (unique), `timestamp`, `entity_id` plus `entity_type` (who did it), and `event_type` (what happened). Fields beyond the minimum feed scoring directly. Industry, employee count, and revenue sharpen Fit. Title, department, and seniority map the buying committee. UTM fields on events carry attribution. Field types, examples, and warehouse DDL are covered when our team sets up your warehouse connection. {% hint style="info" %} Blanks are not neutral. A missing domain or industry silently drops good accounts out of ranking, so completeness on the matching and Fit fields pays for itself. {% endhint %} ## Quality bar | Check | Target | | --------------------------------------------- | ----------------------------------- | | `account_id`, `contact_id`, `event_id` unique | 100% | | `account.domain` present | above 95% | | `contact.email` present | above 95% | | `event.timestamp` present | 100% | | Accounts and Contacts refresh | daily (weekly minimum) | | Events refresh | real-time or hourly (daily minimum) | Run the readiness checks in [Preparing your data](/setup-and-onboarding/preparing-your-data) before connecting, and monitor after connecting in [Data health](/setup-and-onboarding/data-health). ## Outside the app Everything on this page can be inspected outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Workspace and brand Your workspace: what it holds, who can change it, and how many you can have. A workspace is your environment: one company or brand, with its own data, context, team, and settings. Everything the system knows and does lives inside it. ## Workspace details Under **Settings → Workspace** you can rename the workspace. Only the owner and admins can edit workspace details. Your brand itself, what you sound like, who you compete with, how the system stays on-brand, is not a settings form. It lives in your working context, built during onboarding and refreshed as the system learns. You edit it by talking to iHarness, not by filling in fields. ## How many workspaces Each workspace maps to one brand or business unit. The number of workspaces you can own follows your plan: one on Free and Pro, three on Team, and as many as you need on Enterprise. Members you invite join a workspace; owners see all of their workspaces under one subscription and one credit pool. See [Billing](/settings/billing). ## Outside the app Workspace details can be read outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Users and roles Inviting your team, the four roles, and how seats work. You work with iCustomer as a team. Members join a workspace by invitation, and what each person can do is set by their role. ## The roles | Role | What it means | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | | **Owner** | Created the workspace. Full control, including billing and credits. There is one owner, and the role cannot be reassigned from the invite flow. | | **Admin** | Everything but ownership: manage members, settings, and integrations. | | **Editor** | The working role: build audiences, run plays, act on pulses. The default for new invites. | | **Viewer** | Read-only: see everything, change nothing. | ## Inviting members {% stepper %} {% step %} ### Invite Go to **Settings → Workspace → Members** and select Invite. Enter the email and pick a role (Admin, Editor, or Viewer). {% endstep %} {% step %} ### They accept The invitation arrives by email and stays pending until accepted. Invitations expire if unused. {% endstep %} {% step %} ### They sign in Members sign in with Google or with email and a one-time code, and land in your workspace from the workspace picker. {% endstep %} {% endstepper %} ## Seats Seats follow the owner's plan; seat counts per plan live on [icustomer.ai/pricing](https://www.icustomer.ai/pricing). The Free plan is single-player; inviting members starts on a paid plan. Removing a member frees their seat. {% hint style="info" %} Invited members draw on the owner's credit pool as they work. Usage is recorded per member, so you can see who used what. See [Billing](/settings/billing). {% endhint %} ## Outside the app Members and roles can be managed outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # API keys API keys: what they are, how to get one, and how they behave. API keys let your own systems and agents authenticate to iCustomer. They are the credential behind the API and the MCP surface. ## Getting a key Keys are issued by your forward-deployed engineer. Email from your workspace's owner or admin account and say what the key is for. ## How keys behave * A key is shown **once**, at creation. Copy it then. Only a short prefix is displayed afterward. * A key has **full access** to your workspace, so treat it like an owner credential. * Keys are **revocable**, and can carry an expiry. * **Rotation is zero-downtime**: issue the new key, move your integrations over, then retire the old one. ## Keeping keys safe * Store keys in a secret manager, never in code or a shared document. * Rotate on a schedule, and immediately if a key may have been exposed. {% hint style="warning" %} **If a key is compromised**, revoke it right away through your forward-deployed engineer, then issue a replacement. Actions taken with the old key stay on record in your decision traces. {% endhint %} Everything the platform does is also available in the app, and your connected tools authenticate through [your stack](/integrations/stack), not API keys. Agents connect through [Bring your own agent](/iharness/bring-your-own-agent). # Billing Plans, credits, overage, and how billing works across your workspaces. One subscription, owned by the workspace owner, powers everything: the plan, the monthly credits, and every workspace that owner runs. ## Plans Four plans: Free, Pro, Team, and Enterprise. What each unlocks is on [Plans](/getting-started/plans). Current prices, credit allotments, and seat counts are on [icustomer.ai/pricing](https://www.icustomer.ai/pricing). Start on Free and upgrade anytime. Enterprise is custom and starts with a conversation: [book a demo](https://www.icustomer.ai/contact). ## How credits work Credits are the single unit of usage. The system draws credits as it works, and your balance shows in the top bar. * **The pool is the owner's.** Credits are shared across all workspaces the owner runs, and invited members draw from the same pool. Usage is recorded per member and per category (agent sessions, visitor resolution, enrichment, company research) under **Settings → Usage**. * **Fixed costs are flat.** Each action type has a set credit cost, and success-gated actions (like resolving a website visitor) charge only when they succeed. The per-action table is below. * **Included credits work out to 20 per dollar.** Use that to read every cost on this page. * **Credits reset monthly and never roll over.** ## What each action costs Two kinds of charges: **fixed** (a set credit cost per action) and **dynamic** (the cost follows what the work required). ### Fixed charges | Action | US credits | International credits | | --------------------------------------------------- | ---------- | --------------------- | | Company search | 3 | 5 | | Company lookalike | 3 | 5 | | Company lookup | 1 | 2 | | Live company LinkedIn data | 1 | 2 | | Website technologies | 1 | 2 | | Company news search | 3 | 5 | | Company job search | 3 | 5 | | People search | 3 | 5 | | Verified email | 10 | 15 | | Direct phone | 15 | 23 | | Contact bundle (search + email + phone) | 25 | 38 | | Contact lookalike | 3 | 5 | | Visitor de-anonymization (successful resolves only) | 6 | 6 | {% hint style="info" %} **International credits.** The rate follows the location of the contact or account being enriched: an international record draws the international cost, a US record the US cost. {% endhint %} ### Dynamic charges These scale with the work actually done for you: no flat fees, no paying for idle time, credits go where the value went. | Charge | How it accrues | | --------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | **Chat** (working with iHarness interactively) | Credits follow the work your session sets in motion, a quick question stays cheap, a deep build earns its keep | | **iHarness on its own** (always-on, working while you are away) | The same fair draw, with every activity itemized under **Settings → Usage** so you always see what your credits bought | | **Scoring** (FIRE: Fit, Intent, Recency, Engagement) | Scales with the signals gathered to establish real intent, you pay for evidence, never for guesses | Dynamic charges are itemized as they occur under **Settings → Usage**, per activity, so you can always see what your credits bought. {% hint style="info" %} **Example: what a play run draws.** A website-intent play, over one week: * Resolves 120 US visitors: 120 × 6 = **720 credits** (successful resolves only). * 15 accounts turn Hot. Each gets an account lookup: 15 × 1 = **15 credits**. * Each Hot account gets one contact with general profile info: 15 × 3 = **45 credits**. * Visitors who arrived from your outbound campaign already have an email on file: **0 credits**. Fixed draw for the week: **780 credits.** The dynamic charge for the iHarness work that ran it sits on top, itemized under **Settings → Usage**. {% endhint %} ## Changing plans Upgrading takes effect immediately: you get the new plan's full credit allotment right away, and the price is prorated for the time remaining. Downgrades take effect at the end of the paid period. No refunds on unused time or credits. ## Overage When the included credits run out, paid plans can enable overage: billed at 16 credits per dollar, a premium over the included 20, with an optional cap you set. Enabling overage and setting the cap is owner-gated. With overage off, credit-spending actions pause when your balance reaches zero and pick back up when credits reset at the start of your next billing period. | Plan | Overage available | Rate | | ---------- | ----------------------------- | --------------------- | | Free | 0 | - | | Pro | Up to 2,000 credits per month | 16 credits per dollar | | Team | No cap | 16 credits per dollar | | Enterprise | Custom | Custom | ## The billing page **Settings → Billing** shows two things: your subscription overview and your transaction history (subscriptions, renewals, overage, refunds). Payment methods and invoices are managed through the billing portal. Members can see the workspace's subscription. Only the owner changes it. # Preparing your data Get your data ready before connecting: formatting rules, entity relationships, PII handling, and the readiness checklist. Well-prepared data is the difference between a system that decides well and one that guesses. Clean identifiers raise match rates, complete fields keep good accounts in the ranking, and correct links between people and companies make every score sharper. This page is about readiness. What tables you need is covered in [Required tables](/integrations/required-tables); connecting a specific tool is covered in [Your stack](/integrations/stack). ## Formatting rules The matching keys have to be clean, because signals only attach to clean identifiers. | Field | Good | Bad | | --------- | ------------------------------------ | ----------------------- | | Email | `jane@acme.com` (lowercase, trimmed) | `Jane@Acme.com` | | Domain | `acme.com` | `https://www.acme.com/` | | Phone | `+14155551234` (E.164) | `(415) 555-1234` | | Timestamp | ISO 8601 or Unix | `01/15/2024 10:30 AM` | Typical normalization, run in your warehouse before connecting: ```sql UPDATE contacts SET email = LOWER(TRIM(email)) WHERE email IS NOT NULL; UPDATE accounts SET domain = LOWER( REGEXP_REPLACE(REGEXP_REPLACE(domain, '^https?://(www\.)?', ''), '/.*$', '') ); ``` ## Uniqueness and duplicates Primary keys must be unique: duplicate IDs cause scoring errors downstream. ```sql SELECT account_id, COUNT(*) FROM accounts GROUP BY account_id HAVING COUNT(*) > 1; -- should return 0 rows ``` {% hint style="warning" %} Dedupe examples that rely on `ctid` are Postgres-only. On Snowflake, BigQuery, Databricks, or Redshift, dedupe with a window function (`ROW_NUMBER() OVER (PARTITION BY account_id ORDER BY updated_at DESC)`) instead. {% endhint %} ## Link people to companies Every contact should carry an `account_id`. Orphan contacts still score, but they cannot contribute to account-level decisions. ```sql -- find orphans SELECT COUNT(*) FROM contacts c LEFT JOIN accounts a ON c.account_id = a.account_id WHERE a.account_id IS NULL; -- link by email domain (excluding free-mail) UPDATE contacts c SET account_id = a.account_id FROM accounts a WHERE SPLIT_PART(c.email, '@', 2) = a.domain AND c.account_id IS NULL; ``` ## Handling PII You choose how each sensitive field is handled at ingestion: * **Hash**: one-way SHA-256, still usable for matching. The default for email, IP, and device IDs. * **Mask**: partial visibility for operators (`***-***-1234`). * **Encrypt**: reversible, for fields authorized users need to read back. * **Exclude**: not ingested at all. Hashing is consistent within your workspace, so identity resolution and ad-platform matching work without exposing the raw value. Full details live in [Security model](/security-and-compliance/security-model). ## Readiness checklist * [ ] Required fields populated ([Required tables](/integrations/required-tables)) * [ ] Primary keys unique * [ ] Emails lowercase and trimmed; domains cleaned * [ ] Timestamps in a standard format * [ ] Contacts linked to accounts * [ ] `updated_at` columns present for incremental sync * [ ] PII handling chosen per field When the list is green, connect your sources (start with your CRM; see [CRM sync](https://github.com/colby-iCustomer/audience-loop-user-guide-public/tree/main/integrations/crm-sync.md)), then watch [Data health](/setup-and-onboarding/data-health) after you connect. ## Outside the app Readiness checks can be run outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # Data health How the platform validates your data before and after connection, and how to monitor freshness, quality, and sync status. The platform validates your data automatically and keeps watching it after you connect. Health lives in one place, **Settings → Data Health**, and answers three questions: is the data fresh, is it complete, and are the syncs running. ## Validation happens twice {% columns %} {% column %} ### Before connection When you add a source, the platform validates the schema: required tables exist, required columns are present, types are compatible, and a sample reads cleanly. {% endcolumn %} {% column %} ### Continuously after Every sync re-checks freshness, completeness, format compliance, and referential integrity, and flags what it finds. {% endcolumn %} {% endcolumns %} ## What the rules check | Check | Requirement | Severity | | --------------------------------------------------- | -------------------- | ------------------ | | IDs present and unique (accounts, contacts, events) | 100% | Critical | | Email present on contacts | above 90% | Critical | | Domain present on accounts | above 80% | Warning | | Email and domain format valid | pattern match | Warning | | Timestamps present, none in the future | 100% present | Critical / Warning | | Contact-to-account links valid | foreign keys resolve | Warning | You can add custom rules (ranges, patterns, foreign keys, or any boolean SQL expression) per source under **Settings → Data Health**. ## Freshness Each table carries a warning and a critical threshold. Sensible defaults: | Table | Warning | Critical | | ------------------ | ---------- | -------- | | Accounts, Contacts | 1 hour | 4 hours | | Events | 15 minutes | 1 hour | {% hint style="info" %} Stale data usually means the upstream warehouse job is delayed, not that the sync broke. Check your warehouse scheduler first. {% endhint %} ## Sync status and failures The dashboard lists every inbound and outbound sync with its last run, duration, and row count. When a sync fails, the platform shows the error, the records affected, and the auto-retry schedule; you can retry immediately, view logs, or pause the sync. Common causes and fixes: | Issue | Cause | Fix | | ----------------- | --------------------- | ----------------------------- | | Stale data | Warehouse job delayed | Check the warehouse scheduler | | Quality drop | A bad import | Review recent imports | | Sync failure | Expired auth | Re-authenticate the connector | | Validation errors | Schema change | Update the mappings | ## Alerts Health alerts go where your team works: Slack channels or email, with immediate notification on critical failures and a digest for warnings. A daily health report summarizes freshness, quality, and sync status. Delivery preferences are configured in Settings. ## Outside the app Health status can be read outside the app via [API](/settings/api-keys) and [MCP](/iharness/bring-your-own-agent) as well. # What iReveal is iReveal: identity, measurement, and outcome tracking as a standalone product, one tag, running where your data lives. iReveal is the identity and measurement layer as a standalone product: see who is actually on your site, resolve them to real people and companies, and track outcomes against the decisions that drove them, without adopting the full platform first. ## What it does * **Server-side, first-party capture** from one async tag. Not a third-party cookie play. * **Identity resolution** to immutable IDs, for humans *and* for AI agents visiting your site. * **The trace loop**: events, identity, signals, decisions, outcomes, joined end to end, so results are attributable rather than asserted. * **Consent-aware by design.** See [Consent](/ireveal/consent). ## Where it runs In your environment or ours: hosted, or deployed against your own warehouse, including as a Snowflake native app, so capture and resolution happen where your data already lives and nothing needs to leave. iReveal is the proof feed for [Measurement](/measurement-and-outcomes/traces-and-receipts): visitor identity, outcomes, and causal proof, reconciled against what each channel reports about itself. In Enterprise deployments, capture lands in your own warehouse through the native app path. Your deployment plan names the exact landing zone. ## What it is not iReveal is not another web-analytics dashboard, and it does not replace your marketing-mix or incrementality tooling, it complements them by supplying the identity-resolved, outcome-joined ground truth those models want as input. Compared to visitor de-anonymization point tools, the difference is the loop: not just *who was here*, but *what came of it*. ## From iReveal to the platform iReveal is a complete product on its own and the natural first step into the full platform: the identities and outcomes it builds are exactly what the loop runs on. See [Upgrade path](/ireveal/upgrade-path). # Outcome tracking and holdouts Outcome tracking and holdouts in iReveal: every decision carries its result in a single trace, and incrementality is measured against counterfactuals. Analytics ends at conversions and e-commerce events; pipeline and revenue live somewhere else, and the connection between the two is asserted, not shown. iReveal closes that gap: **every decision carries its result in a single trace**, and the trace ends in pipeline and revenue impact, not pageview counts. ## The trace A trace is the full lineage from event to outcome: the visit that was captured, the identity it resolved to, the signal it produced, the decision that acted on it, and what came of that decision. Because the chain is one object, attribution is something you read, not something you model after the fact, and the record is audit-ready. The trace structure is the same one the full platform uses; see [Decisions and traces](/concepts/decisions-and-traces). ## Holdouts and causal measurement Correlation is what last-touch attribution sells you: what coincided with the number moving. iReveal measures **incrementality against counterfactuals**: what actually moved the number. Holdouts are how the counterfactual exists at all, a portion of eligible records held back so the lift of acting can be read against the cost of not acting. ## Alongside your MMM Marketing-mix models and geo-lift tools measure channel-level lift on aggregate data, with no pixel and no user-level tracking, and they are strongest on channels like TV, CTV, and out-of-home. iReveal is trace-level: person-, SKU-, and decision-level causality that also recovers signal and activates. {% hint style="info" %} Complementary, not substitutes: iReveal's holdouts are the calibration experiments an MMM consumes. {% endhint %} # AI-referral measurement AI-referral measurement in iReveal: agents and LLM referrals as a first-class, identified, measurable channel. AI agents acting on your behalf, and on your visitors' behalf, are invisible to session analytics. A browsing agent does not accept a cookie banner the way a person does, does not stitch into a session model built for humans, and does not show up in a channel report that only knows paid, organic, and direct. Traffic from AI assistants and LLM answers is already arriving; most measurement stacks cannot see it, let alone credit it. ## Agents are first-class actors iReveal treats humans **and agents** as first-class, identified actors. An agent's visit resolves to an immutable ID the same way a person's does, its actions are captured server-side at full fidelity, and what came of them lands in the same trace, from event to identity to outcome. ## LLM referrals as a channel That makes AI referral a channel you can measure rather than a mystery slice of direct traffic: see the visits AI referrals drive, follow them to resolved people and accounts, and read what those referrals produced in pipeline and revenue, on the same [outcome tracking](/ireveal/outcome-tracking) every other channel gets. # Consent How iReveal respects consent: your banner decides, capture is first-party, and opt-outs travel. iReveal is consent-aware by design, and the design is simple: **your consent banner decides; iReveal obeys.** ## The tag loads on consent The iReveal tag is gated by your consent management platform like any analytics tag: wire it to load only after the visitor consents, using your CMP's consent-granted callback. No banner interaction, no capture. The wiring pattern is the same as the platform pixel's; see [Events and pixels](/integrations/events-and-pixels). ## First-party, in your environment Capture is server-side and first-party, under your domain and your policies, and with warehouse deployment it runs inside your own environment, so visitor data does not leave your control to be resolved. ## Opt-outs travel A visitor who opts out stays opted out downstream: suppression and consent flags ride with the record into scoring, audiences, and any activation. Deletion and access requests follow the platform's DSAR support; see [GDPR, CCPA and DSAR](/security-and-compliance/gdpr-ccpa-dsar). {% hint style="info" %} Regional rules differ, and your legal team owns the consent policy. iReveal's job is to make the compliant configuration the easy one: one tag, gated by your banner, honored everywhere downstream. {% endhint %} # 30-day POC The 30-day iReveal POC: discover, deploy, evaluate, on your traffic, with full decision rights retained throughout. iReveal proves itself on your traffic, not in a demo. A POC runs 30 days on your site and ends in a joint review against success metrics you agreed to before anything went live. Until that review, nothing is committed. {% stepper %} {% step %} ### Week 1: Discovery A tag audit of your site, a walkthrough with your privacy or legal team where your jurisdiction calls for one, and success metrics fixed jointly. Data processing terms are signed before any live data moves. {% endstep %} {% step %} ### Week 2: Deploy The tag goes live and resolution starts, hosted or against your own warehouse, in the data plane your compliance posture requires. Consent gating is wired to your banner from the first event; see [Consent](/ireveal/consent). {% endstep %} {% step %} ### Weeks 3 and 4: Evaluate Resolved accounts flow daily while the evaluation runs. The POC closes with a joint review of what iReveal found against the metrics agreed in week 1. {% endstep %} {% endstepper %} ## The ground rules * You retain full decision rights throughout. * No commitments before the joint review. * Consent first: capture is gated by your banner from day one, and no automated individual decisions are made about the people identified. ## What a good POC measures The point is not traffic counts; analytics already gives you those. A POC is judged on what was previously invisible: how much of your anonymous traffic resolved to real accounts, which of those accounts your team would actually want, and what came of the ones you acted on. ## What you get back Thirty days in, you hold four things: * a **resolved-account list**, built daily from your own traffic, * the **resolution rate** on your site, measured, not estimated, * **outcome evidence** for the accounts you acted on, joined end to end, * and a **joint review** against the success metrics you set in week 1, before anything was committed. # Upgrade path From iReveal to the full platform: the same spine, with the decision layer turned on. No migration, no re-tagging. iReveal is a complete product on its own. It is also, by design, the first half of the platform already running: the identities it resolves, the events it captures, and the outcomes it joins are exactly what the loop runs on. Upgrading is not a migration; it is turning on the rest. ## What carries over Everything. The tag stays the same tag. The immutable IDs stay the same IDs. The traces you have been accumulating become the history the platform learns from, and the consent state and suppression you enforced ride along untouched; see [Consent](/ireveal/consent). ## What turns on * **The loop**: goals, KPIs, and targets over the audience iReveal has been building. See [The loop in one page](/getting-started/the-loop). * **iHarness and plays**: decisions stop ending at a resolved-account list and start acting, within the gates and approvals you set. See [What iHarness does](/iharness/what-it-does). * **Pulse**: the moments that need you, raised instead of buried. ## When to upgrade The honest tell is what you do with iReveal's output. If resolved accounts are being exported to a spreadsheet and worked by hand, the loop is already running, just with people as the decision layer. Plans and what each unlocks are on [Plans](/getting-started/plans). # Glossary Every term used across iCustomer Platform, A to Z. The full reference, A to Z. For the short version in loop order, see the [Getting Started glossary](/getting-started/glossary). | Term | Meaning | | ----------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **ABC Card** | Audience, Brand & Competition: the picture the system builds of your business from your domain, which you confirm or correct during onboarding. Your confirmation turns it into working context. | | **Activation** | What a play's run delivers into a destination: the live push of an audience to a channel like LinkedIn, Instantly, or your CRM. One play can produce many activations. (On the sales side, "activation" can also mean a user starting to use a product. In these docs it always means the platform object.) | | **Agent** | A specialized worker iHarness coordinates behind the scenes, each covering one part of the loop. You see agents as bylines on the work they deliver. See the [Agent catalog](/reference/agent-catalog). | | **Cohort** | A named group of accounts or contacts under a segment, defined by a shared trait or behavior. Cohorts are what you build, monitor, and activate. | | **Credits** | The single unit of usage every plan includes. The system draws credits as it works, and your balance shows in the top bar. | | **Decision** | A moment where iHarness chose one option over others, spent something finite doing it, and said what it expected to happen. The unit of work. Anything without all three is a step. | | **Decision trace** | The receipt for a decision: why it was made, on what evidence, under what authority, and what came of it. | | **FIRE score** | Fit, Intent, Recency, and Engagement, combined into a tier so you know who is worth acting on right now. See [FIRE scoring](/audience/fire-scoring). | | **Goal** | One of six fixed go-to-market ambitions. Your standing focus, and goals never expire. | | **Growth Brain** | The self-learning context graph iHarness runs on: customer, company, and audience context, built on OneSource identity, accruing from every connected system and every decision outcome. iHarness's memory and the Growth Brain are the same thing. See [Context and memory](/concepts/context-and-memory). | | **iConnect** | The integrations layer: activation out, governed connection in. The only part of the platform that touches your systems. See [Your stack](/integrations/stack). | | **iHarness** | The agent running your growth loop. It reasons over your Growth Brain, decides what to do, and coordinates the agents, on request and on its own. It executes, within guardrails. | | **KPI** | What the business can actually read: a measurable number under a goal. If no connected source makes it readable, it is not a KPI for that workspace. | | **Learning** | The recorded difference between what a decision expected and what actually happened, so the next decision is better. | | **The loop** | The always-on cycle behind everything: capture what is happening, resolve who it is, score it, decide what to do, and attribute what came of it, then back to the top. | | **OneSource ID** | The immutable identity a verified match earns, and the foundation the Growth Brain is built on. Licensed third-party data enters only by resolving to a OneSource ID, and deletion requests propagate at the same level. | | **Outcome** | What happened, measured against what was expected. Outcomes move targets, and targets move KPIs. | | **Pixel** | The snippet on your site that reveals who is visiting and ties anonymous visits to real accounts. | | **Meta loop** | The slower loop underneath the 90-day loop: outcomes become evidence, and evidence sizes the next target. It runs across quarters and never closes. | | **Play** | A named, repeatable piece of work that moves a KPI: picked from the library, made yours for your workspace, and editable through the chat where it was created. Plays have runs. | | **Playbook** | Retired term, see Play. Some internal identifiers keep the historical name. | | **Pulse (the surface)** | Where the system raises its hand: the queue of things that need you to see or decide. **A pulse (an item)** is one such card. | | **Run** | One execution of a play. Each run delivers into an activation. | | **Segment** | The top-level split of your market: B2B or D2C. Cohorts live under segments. | | **Signal** | An event or behavior that tells the system something changed: a site visit, a demo request, a funding round. | | **Suppression** | The records a play must not touch: your exclusion lists, consent boundaries, and the one-cadence-per-contact rule. | | **Target** | An achievable, computed commitment: a number and a date under a goal, moved by outcomes. A number that cannot be reached is not a target. | | **Workspace** | Your environment: one company or brand, its data, team, and settings. | # Agent catalog The specialized agents iHarness coordinates, what each covers, and where you see their work. iCustomer Platform is not one model in a chat box. Behind [iHarness](/iharness/what-it-does) works a team of specialized agents, each an expert in one part of the loop. You never manage them, and you never talk to them directly: iHarness owns the conversation, routes the work, and the agents deliver. Their names appear as bylines on the work they produce, so you always know which specialist did what. The team, mapped to the loop: | Agent | Specialty | What it covers | | ------- | -------------------------- | ----------------------------------------------------------------------- | | Sam | Market intelligence | Reads your market and surfaces what is moving. | | Ivy | Identity and data | Resolves events to real people and accounts, and keeps your data clean. | | Angela | Audience intelligence | Builds and enriches your audiences, and knows who they are. | | Joel | Growth ops and decisioning | Turns goals into the next move for each audience. | | Brandon | Paid media | Activates and tunes paid distribution. | | Lina | Outreach | Runs outbound and moves pipeline. | | Mira | Measurement | Measures what worked and feeds it back. | Where you meet them: a byline on a delivered artifact ("researched by Sam, market intelligence"), a name on a draft card, a credit in a [decision trace](/concepts/decisions-and-traces). In conversation there is only one voice, iHarness. The team is pre-built and comes with every plan; there is nothing to configure. # Play library The catalog of plays: what each one does, the goal it moves, and what it needs. The catalog of plays. What a play is, and how plays run, is covered in [What a play is](/plays/what-is-a-play). Search the table by play name, by goal, or by the tool it uses; the catalog grows as new plays land. | Play | Goal | What it does | Uses | | -------------------------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | **Convert Anonymous Traffic** | Pipeline growth | Finds out who is on your site, scores them with the reason attached, and reaches the good ones by email or DM | HubSpot, Salesforce, Instantly, SmartLead, LinkedIn, Meta. Pixel required | | **Escalate In-Market Accounts** | Pipeline growth | Gets buying-intent visitors to your team within a day, or as a Monday lead package | HubSpot, Salesforce, Instantly, SmartLead, LinkedIn, Meta. Pixel required | | **Target Accounts That Are Hiring** | Pipeline growth | Reaches accounts in the window right after they hire the person who owns your problem | OneSource, HubSpot, Salesforce, Instantly, SmartLead, LinkedIn | | **Find More Like Your Best Customers** | Pipeline growth | Turns your closed-won pattern into a net-new audience and markets to it | HubSpot, Salesforce, OneSource, Instantly, SmartLead, LinkedIn, Meta, Google | | **Nurture Good-Fit Accounts** | Pipeline growth | Keeps good-fit accounts warm until they are ready, then hands them over the moment they are | HubSpot, Salesforce, Instantly, SmartLead, LinkedIn, Meta | | **Target Event Attendees** | Pipeline growth | Reaches the buyers gathering at the events your ICP already attends | OneSource, HubSpot, Salesforce, Instantly, SmartLead, LinkedIn, Meta | | **Convert Product-Qualified Accounts** | Product-led growth | Turns product usage into pipeline the moment an account crosses your PQL bar | HubSpot, Salesforce, Instantly, SmartLead. Product events required | | **Rescue At-Risk Customers** | Retention and expansion | Catches customer accounts going quiet before the renewal conversation gets hard | HubSpot, Salesforce, Instantly, SmartLead | | **Grow Social Engagers Into Known Audience** | Brand and community | Turns the people engaging your posts into a scored, reachable audience | LinkedIn, HubSpot, Salesforce, Instantly, SmartLead, Meta | | **Reactivate Stale CRM Contacts** | GTM efficiency | Puts the leads already sitting in your CRM back to work before you buy new ones | HubSpot, Salesforce, Instantly, SmartLead | | **Target Tech-Stack Adjacent Accounts** | GTM efficiency | Reaches accounts already running the tools you integrate with | OneSource, HubSpot, Salesforce, Instantly, SmartLead, LinkedIn | ## The library grows New plays land as the signals and connectors they need arrive; a play you cannot run yet appears as coming soon with what would unlock it, never hidden. Every play inherits the platform rules, one active cadence per contact, your suppression lists, consent respected, CRM updated rather than overwritten. See [Guardrails and suppression](/plays/guardrails-and-suppression). # Pulse families The pulse family catalog: Opportunity, Stall (with its five edges), and Milestone, with examples of each. Every pulse belongs to exactly one family. Three families cover everything the system raises. | Family | The moment | Examples | | --------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | **Opportunity** | Something good is happening. Act before the window closes | A target account is back on your pricing page, a hot reply landed, someone raised their hand on a form | | **Stall** | An edge of the loop cannot advance. The reason and the remedy come attached | A sync is failing, a play is waiting at its gate for your approval, a connector lost authorization | | **Milestone** | A first, worth marking | First audience activated, first outcome attributed, a target reached | ## The five stall edges Anyone can build the path where everything works. What matters is what you see when something doesn't. At every step of [the loop](/getting-started/the-loop), the platform either advances or tells you exactly what's in the way, and every stall names the edge it fired from: | Edge | Stalls when | What you get | | ---------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------------------------------- | | Goal → KPI | Nothing under the goal is readable | The goal marked locked, the connector that opens it, and how many KPIs and plays that unlocks | | KPI → Target | No achievable move, or the window is shorter than your sales cycle | "No target here yet," naming which of baseline, reference, or portfolio is missing | | Target → Play | Capacity, a missing connector, or missing required data | A setup proposal: what to connect or configure, and what it would make possible | | Play → Outcome | Plays ran and nothing landed | A prompt to re-diagnose. Never a second play stacked on the same theory | | Outcome → Target | Identity doesn't resolve | The outcome counted, credited to nothing, and reported | Refusing to set a target is a feature. Any tool will happily produce a number. Saying "we won't guess, and here's what would let us know" is the more useful answer, and it's what the system actually believes rather than a bit of interface politeness. A stall that needs your click (an approval, a merge proposal, a gated play) is still a stall: the human is the remedy. A stall that fires early (credit pacing, "you run out by this date") is a forecast of the same shape. ## Mode and origin * **Mode.** A pulse is either **decide** (it needs an action from you) or **inform** (it tells you something worth knowing and folds into the digest). Only decide pulses can interrupt. * **Origin.** Pulses are generated at the moment they fire, from what the system actually observed. Pre-written sequences, like onboarding nudges, are lifecycle email, not pulses. How the queue behaves, and how families relate to the app's tabs, lives in [Families](/pulse/families). Acting on a pulse is covered in [Acting on a pulse](/pulse/acting). # Security model How iCustomer Platform protects your data: encryption, workspace isolation, PII handling, consent-aware activation, and access control. Your data runs your go-to-market. The platform is built so it stays yours. ## The basics * **Encryption everywhere.** Data is encrypted in transit and at rest. * **Workspace isolation.** Each workspace's data, context, and memory are its own. Nothing is shared across workspaces or tenants. * **Your data never trains public models.** What the system learns from your workspace stays in your workspace. * **Access is role-based.** Who can see and change what is governed by [users and roles](/settings/users-and-roles). Sign in with Google or with email and a one-time code. API access uses scoped, revocable keys. ## Where it runs * **Enterprise** runs in your cloud or warehouse. "Zero egress" means exactly this: no warehouse data leaves except governed, customer-approved activations. The connection is in place, and nothing is copied out to run the platform. * **SMB** runs in our managed cloud. Same architecture, different home. ## Third-party data never enters raw * Licensed data from our 50+ data vendors is resolved to OneSource IDs before it reaches your audiences. * It is never written raw into your CRM or media accounts. * You see one counterparty and one meter, iCustomer credits, with no vendor contracts of your own. * Deletion requests propagate at the OneSource ID level, which keeps provenance clean. ## PII handling, per field You choose how each sensitive field is handled at ingestion: * **Hash**: one-way, still usable for identity matching and ad-platform audiences without exposing the raw value. * **Mask**: partial visibility for operators. * **Encrypt**: reversible, for fields authorized users need to read back. * **Exclude**: not ingested at all. Hashing is consistent within your workspace, which is what lets identity resolution and audience matching work on protected values. ## Consent-aware by design Consent and suppression flags travel with your data and flow into every activation. Suppressed records are excluded before anything reaches a destination, and opt-outs are honored across channels. See [Guardrails and suppression](/plays/guardrails-and-suppression). ## More detail The full control set runs from deny-by-default network rules and encrypted backups to annual risk and vendor assessments. Detailed policies and our sub-processor list are available on request from your iCustomer contact. Our [Privacy Policy](https://www.icustomer.ai/privacy-policy) covers data handling in full. For compliance programs, see [SOC 2](/security-and-compliance/soc2) and [GDPR, CCPA and DSAR](/security-and-compliance/gdpr-ccpa-dsar). # SOC 2 iCustomer's SOC 2 program and how to request the report. iCustomer maintains a SOC 2 compliance program covering security, availability, and confidentiality, and it applies on every plan, not only Enterprise. Our CPA-attested SOC 2 Type 2 report is available here: [iCustomer SOC 2 Type 2 report](https://drive.google.com/file/d/1ZF3y5EmfKu9Qnsz97tCCTMvLa52jQMJG/view). For supporting policies and further documentation, ask your iCustomer contact. For how the platform protects data day to day, see the [Security model](/security-and-compliance/security-model). # GDPR, CCPA and DSAR How iCustomer Platform supports GDPR and CCPA compliance, and how data subject requests are handled. The platform is built to operate inside privacy regulation, not around it. ## What that means in practice * **Opt-outs are honored.** Consent and suppression flags travel with records and are enforced before any activation reaches a destination. * **PII is protected at ingestion.** Hash, mask, encrypt, or exclude sensitive fields per your policy. See the [Security model](/security-and-compliance/security-model). * **Deletion and access requests are supported.** When a data subject exercises their rights, the corresponding records can be exported or removed across the platform. ## Data subject requests (DSARs) Route data subject requests through your own privacy process as the controller. As a processor, iCustomer supports fulfillment: locating the subject's records, exporting them, and deleting them on instruction. Contact your iCustomer administrator or reach us through the [Privacy Policy](https://www.icustomer.ai/privacy-policy) channels to initiate a request. ## Documentation Our sub-processor list, Data Processing Agreement, and data-handling policies are available on request from your iCustomer contact. Deletion requests propagate at the OneSource ID level, which is what keeps provenance clean across every source that contributed to a record. # Release notes What shipped, what changed, and what is coming next in iCustomer Platform. ## What's new: August 2026, iCustomer Platform The platform launches: one system that learns your business, builds and scores your audiences, runs plays across your channels, and records the reasoning behind every move. * **Onboarding from your domain.** Paste your URL, confirm the picture the system builds of your audience, brand, and competition, and go. * **The pixel on every plan.** See who is visiting your site by name, on the free plan included. * **Audience with FIRE scoring.** Your accounts and contacts under management, scored on Fit, Intent, Recency, and Engagement. * **Plays.** Proven go-to-market motions you run from a library, leaving activations in your channels: HubSpot, Salesforce, Instantly, LinkedIn, Reddit, and more. * **Pulse.** The system raises its hand when something needs you; everything else stays handled. * **iHarness.** Ask anything, in the app or in Slack, and watch the reasoning behind every decision. ## Changelog ### 2026-08 * iCustomer Platform launch. The always-on system: onboarding from your domain, Audience with FIRE scoring, the play library, Pulse, iHarness, and integrations across CRM, outbound, and paid channels. * Audience replaces Explorer in the left navigation. * HubSpot integration live, with CRM writes behind per-tool approvals. * Visitor de-anonymization available on every plan, including free. Entries are added as releases ship. ## Upcoming The platform ships in waves. On the way: * **More plays.** The library grows past the launch set; plays that need a signal the platform does not capture yet arrive as their connectors land. * **More connectors.** Meta Ads, Klaviyo, Google Ads, and PostHog product events are in progress. * **Outcome tracking against targets.** Watching a target move as outcomes land, with the trace to show why. * **CLI and API access.** {% hint style="info" %} CLI and API access are not available at launch. To get early access, join the beta waitlist: [contact us](https://www.icustomer.ai/contact). {% endhint %} Roadmap items are directional and can change.