Customer.io Custom Objects: The Complete Guide to Account-Level Messaging for B2B and Multi-Seat SaaS

In 1929, a German archaeologist named Julius Jordan unearthed a library of clay tablets in Uruk, a Mesopotamian city on the banks of the Euphrates in what is now Iraq. The tablets were 5,000 years old—the oldest known writing on earth. Scholars expected poetry. They expected religion. What they found instead was accounting.

As the French archaeologist Denise Schmandt-Besserat later demonstrated to the BBC, the tablets recorded the movement of grain, cattle, and jars of honey between parties who may never have met face-to-face. The Sumerians had invented writing not to tell stories, but to track relationships between entities: who owed what to whom, which storehouse held which goods, how obligations were linked across a web of different parties.

The Library of Congress holds some of these tablets today. Researchers have confirmed they contain tax assessments, payment records, and multi-party contracts—evidence that the ancient world understood something modern SaaS marketers are still catching up to: the most important unit of commerce isn't the individual. It's the account.

Five thousand years later, most marketing automation platforms still treat every person as a standalone entity. A user signs up. You fire a welcome email. They go quiet. You fire a re-engagement email. The whole system is built around a single human being, with no concept of the account they belong to, the team they're part of, or the contract their company is halfway through.

Customer.io Custom Objects change that. They let you model your business the way the Sumerians modelled theirs—as a web of relationships between entities—and then trigger messaging based on the state of those relationships, not just the behaviour of one person.

This guide explains exactly how.


What Are Customer.io Custom Objects?

Custom Objects are a data structure in Customer.io Journeys that lets you represent non-person entities—accounts, subscriptions, workspaces, deals, courses, properties—and connect them to the people in your workspace through defined relationships.

Think of it this way:

  • Person data tells you about an individual: their name, their email, their last login date.
  • Event data tells you what they did: they clicked a button, they upgraded a plan.
  • Custom Objects tell you what they belong to and what the state of that thing currently is.

A Custom Object for an Account might carry attributes like:

  • plan_type: "Growth"
  • contract_end_date: "2025-12-31"
  • health_score: 42
  • seats_purchased: 10
  • seats_active: 2
  • mrr: 499

Every person related to that account inherits access to those attributes in your campaigns. When the account's health_score drops below 50, Customer.io can trigger a campaign and send a message to every admin on that account—not because any individual did anything, but because the account state changed.

That's the conceptual shift. You're no longer just watching what people do. You're watching what their world looks like.


Why Person-Centric Messaging Breaks Down in B2B SaaS

In B2B and multi-seat SaaS, the person is rarely the unit of value. The account is.

When Acme Corp pays you $2,400 a year, they're not paying as twelve individual users. They're paying as one account with twelve seats. When Acme Corp churns, twelve users leave at once. When you win them back, you win back twelve users at once.

And yet, most messaging setups track each of those twelve people in isolation. User A hasn't logged in for 30 days—send them a re-engagement email. User B hasn't logged in either—send them the same email. The system has no idea that the whole account went dark simultaneously, which is a completely different signal with completely different implications.

According to Vitally's 2025 churn benchmarks, customer health scores that combine usage, engagement, and relationship signals can predict 85% of churn events before they happen. But you can only build those scores if you're modelling the account as a whole—not twelve fragmented individual profiles.

The problem compounds in multi-seat environments where:

  • Different users have different roles. The admin cares about billing and permissions. The end user cares about the feature they use every day. The executive sponsor cares about ROI. Person-centric messaging treats them identically.
  • Decisions happen at the account level. Renewals, upgrades, and cancellations are account decisions, not individual ones. Messaging an end user about a renewal is often pointless. Messaging the account admin at the right time is the entire game.
  • Churn signals are account-level signals. One user going quiet might mean nothing. The whole team going quiet means the account is at risk.

Custom Objects give you the infrastructure to model this reality accurately.


The Four Custom Object Types Every B2B SaaS Should Build

1. Accounts

Your most important object type. An Account represents the company or organisation that pays you.

Key attributes to track:

Attribute Type Purpose
plan_type string Segment messaging by tier
mrr number Prioritise high-value accounts
contract_end_date timestamp Trigger renewal campaigns
health_score number Identify at-risk accounts
seats_purchased number Compare against active usage
seats_active number Spot adoption gaps
last_team_activity timestamp Account-level inactivity signal
csm_owner string Route to the right sender
account_stage string e.g., onboarding / active / at-risk

Relationship attributes (the data that lives on the link between a person and an account, not on either entity itself):

  • role: admin / member / viewer / billing_contact
  • joined_at: when this person was added to the account
  • last_active: this specific user's last activity date

2. Subscriptions

A Subscription object captures the commercial relationship, separate from the account itself. This is especially useful if accounts can have multiple active subscriptions (add-ons, different product lines, legacy plans).

Key attributes:

  • status: active / past_due / cancelled / trialing
  • billing_cycle: monthly / annual
  • renewal_date
  • plan_name
  • trial_end_date
  • payment_method_status: valid / expiring / failed

3. Workspaces

For product-led growth tools, dev tools, or collaboration platforms, a Workspace often maps more naturally than an Account. The workspace is the product container—it has members, it has activity, it has a health state.

Key attributes:

  • workspace_name
  • member_count
  • dau_last_7_days
  • feature_adoption_score
  • primary_use_case
  • integration_count

4. Deals (CRM-adjacent)

For companies that track pipeline or use Customer.io alongside a CRM, a Deal object lets you trigger messaging based on commercial milestones: a deal moves to a new stage, a proposal expires, a trial converts.

Key attributes:

  • deal_stage
  • estimated_close_date
  • deal_value
  • proposal_sent_date
  • decision_maker_id

How to Send Custom Object Data to Customer.io

Customer.io supports several ingestion methods. Here's what each looks like in practice.

Via the Pipelines API (Recommended)

The Pipelines API uses a group call to create or update an object and relate it to a person in one request:

curl --request POST \
  --url https://cdp.customer.io/v1/group \
  -u api_key: \
  -H 'content-type: application/json' \
  --data-raw '{
    "userId": "user_42",
    "groupId": "acme-inc",
    "traits": {
      "objectTypeId": 1,
      "name": "Acme Inc.",
      "plan_type": "growth",
      "contract_end_date": "2025-12-31",
      "health_score": 38,
      "seats_purchased": 10,
      "seats_active": 2,
      "last_team_activity": 1704067200,
      "relationshipAttributes": {
        "role": "admin"
      }
    }
  }'

Via the Track API v2

Use the Track v2 API to identify an object and relate it to multiple people in a single call:

curl --request POST \
  --url https://track.customer.io/api/v2/entity \
  --header "Authorization: Basic YOUR_ENCODED_CREDENTIALS" \
  --header 'content-type: application/json' \
  --data-raw '{
    "type": "object",
    "identifiers": {
      "object_type_id": "1",
      "object_id": "acme-inc"
    },
    "action": "identify",
    "attributes": {
      "name": "Acme Inc.",
      "plan_type": "growth",
      "health_score": 38,
      "contract_end_date": "2025-12-31",
      "seats_purchased": 10,
      "seats_active": 2
    },
    "cio_relationships": [
      { "identifiers": { "id": "user_42" } },
      { "identifiers": { "email": "[email protected]" } }
    ]
  }'

Via Reverse ETL

If your account data lives in a data warehouse (Snowflake, BigQuery, Redshift), you can sync it to Customer.io on a schedule using a Reverse ETL integration. This means your health_score, seats_active, and contract_end_date stay current without requiring any application-level instrumentation. Your data team writes a SQL query; Customer.io reads it on a schedule and updates the objects automatically.

Via CSV Import

For teams just getting started, Customer.io supports CSV import for objects and relationships. It's not designed for real-time updates, but it's a fast way to seed your workspace with account data and start experimenting with object-triggered campaigns before you've built full API integration.


Building Account-Level Campaigns: The Conceptual Framework

Once your objects are in place, you can build campaigns that trigger on object-level changes rather than person-level events.

Customer.io lets you trigger campaigns when:

  1. An object attribute changes — e.g., health_score drops below 50
  2. A relationship is added — e.g., a new user is added to an account
  3. A relationship is removed — e.g., a user leaves an account
  4. An object is created — e.g., a new account is provisioned

For each trigger, you choose who receives the campaign:

  • Every person related to the object — broadcast to the whole team
  • Certain people in the object — filtered by relationship attributes (e.g., only admins)
  • Only the person who triggered the relationship change — individual targeting within an account context

This combination—object-state triggers plus relationship-attribute audience filtering—is what makes account-level messaging genuinely powerful.


Real Campaign Examples

Example 1: Account-Level Win-Back When the Whole Team Goes Inactive

The scenario: You have a Growth plan account with eight users. Over the past 45 days, every single one of them has stopped logging in. Your CRM shows no support tickets, no recent emails opened, no feature activity. The account has gone completely dark.

A person-centric system sees eight separate "inactive user" records. Each one might trigger an individual re-engagement email, all firing at slightly different times, all sounding like generic "we miss you" messages.

A Custom Objects setup sees one account with last_team_activity that hasn't updated in 45 days. It triggers a single, coordinated account-level win-back campaign, and it routes the message strategically.

How to build it:

  1. Your backend updates the account object's last_team_activity attribute whenever any member of the team logs in. If 45 days pass without an update, this value ages.
  2. Create a segment: Accounts where last_team_activity is more than 45 days ago.
  3. Create an object-triggered campaign: fires when an account joins this segment.
  4. Audience: people related to this account where relationship attribute role equals admin.
  5. The admin receives a high-touch win-back email—not a generic re-engagement nudge, but a message that acknowledges the account has gone quiet and offers a concrete path back.

The email might read:

"Hi Sarah — I noticed your whole team at Acme has been away from [Product] for a while. That sometimes means something changed, or maybe you hit a wall we could help with. I'd love to jump on a 15-minute call this week. Here's my calendar link."

This message wouldn't make sense if it came from a person-level trigger. It only makes sense because you're watching the account.


Example 2: Renewal Nudge Based on Contract End Date

The scenario: You have an annual contract customer with a contract_end_date stored on their Subscription object. You want to trigger a renewal campaign 90 days, 60 days, and 30 days before that date—but only to the billing contact and admin, not to every end user on the account.

How to build it:

  1. Your Subscription object carries a contract_end_date attribute (Unix timestamp or ISO date string).
  2. Create three object-triggered campaigns, each using a time-based filter:
    • 90 days before contract_end_date: value-reinforcement email to admins, surfacing ROI data and usage stats from the past year
    • 60 days before contract_end_date: upgrade conversation email to admins and billing contacts, with a comparison of current plan vs. higher tier
    • 30 days before contract_end_date: urgency email with renewal link and a direct calendar booking CTA
  3. For each campaign, filter audience to relationship attribute role is admin OR billing_contact.

You can personalise every email with the account's own object data using Liquid:

Hi {{ customer.first_name }},

Your {{ relationship.plan_type | capitalize }} plan at {{ account.name }} renews 
on {{ account.contract_end_date | date: "%B %-d, %Y" }}.

Over the past year, your team has {{ account.seats_active }} active users 
across {{ account.seats_purchased }} seats.

No developer needed to pull this data at send time. It lives on the object, Customer.io reads it, and Liquid renders it into the email.


Example 3: Seat Utilisation Campaign

The scenario: An account bought 20 seats but only 6 are active. This is both a churn signal (they may question the value of paying for 14 unused seats) and an expansion opportunity (if you can activate the dormant seats, you increase stickiness).

How to build it:

  1. Your backend calculates adoption_rate = seats_active / seats_purchased and stores it on the account object.
  2. Create a segment: Accounts where adoption_rate is less than 0.40 (less than 40% of seats active).
  3. Trigger a campaign when an account joins this segment.
  4. Send to admins only.

The email surfaces the gap directly:

"Hey Marcus — your team has 20 seats on your Acme account but only 6 are actively used. Here are three things that usually help teams get more people onboarded quickly..."

You can also branch this campaign: if seats_active is 0–3, route to a high-touch CSM outreach. If seats_active is 4–10, send a self-serve onboarding guide. If seats_active is 11+, send a feature adoption nudge. The branch logic lives in a multi-split branch in the journey builder, conditioned on the account object's attributes.


Example 4: Plan Downgrade Early Warning

The scenario: A customer on your Enterprise plan hasn't used a single premium feature in 90 days. Their health_score has been declining. Their contract_end_date is in 120 days. Based on this cluster of signals, you want to trigger a proactive success outreach before they ask to downgrade.

How to build it:

  1. Track premium_feature_last_used and health_score on the account object, updated by your backend.
  2. Create a segment: accounts where plan_type equals enterprise AND health_score is less than 45 AND premium_feature_last_used is more than 60 days ago.
  3. Trigger a campaign when an account enters this segment.
  4. Route to the assigned CSM (you can store csm_owner_email on the account object and use it as the sender in the campaign).

The message doesn't come from a generic marketing address. It comes from the CSM, personalised with account-specific data, and it leads with the account's actual usage reality—not a generic "we noticed you haven't been around" template.


Example 5: New User Onboarding That Knows the Account Context

The scenario: A new user joins an existing account that's already on an Enterprise plan. They should get a different onboarding experience than a user who just signed up for a 14-day trial on the Starter plan.

How to build it:

  1. Trigger a campaign when a relationship is added between a person and an account object.
  2. Use a multi-split branch based on the account's plan_type attribute:
    • starter: self-serve onboarding flow, documentation links, in-app tooltips
    • growth: guided onboarding with a product tour invitation
    • enterprise: white-glove sequence, CSM introduction, personalised kickoff call booking

The new user gets an onboarding experience that reflects their team's actual context—not a one-size-fits-all welcome sequence designed for the average user who doesn't exist.


Using Liquid to Personalise with Object Data

Once your objects carry the right attributes, Liquid makes it trivial to pull them into messages. Customer.io exposes object data through the relationship and the object-type reference in your templates.

Some practical examples:

Reference the account name:

Welcome to the team at {{ account.name }}!

Reference the user's role on the account:

{% if relationship.role == "admin" %}
As the account admin, you have access to billing, user permissions, and API keys.
{% else %}
Here's a quick tour of the features you'll use most.
{% endif %}

Show the contract end date:

Your annual plan renews on {{ account.contract_end_date | date: "%B %-d, %Y" }}.

Show seat utilisation:

Your team is using {{ account.seats_active }} of {{ account.seats_purchased }} available seats.

Branch based on health score:

{% if account.health_score < 40 %}
We'd love to set up a call to make sure you're getting full value from the platform.
{% elsif account.health_score < 70 %}
Here are some features your team hasn't explored yet that could save you hours every week.
{% else %}
You're getting great value from the platform. Here's what's new this month.
{% endif %}

This is the kind of personalisation that was previously only possible if you had a developer hand-crafting dynamic emails with live API calls at send time. Custom Objects make it a standard marketer operation.

For a deeper dive into Liquid syntax in Customer.io, see our guide on Customer.io Liquid personalisation for marketers.


How Custom Objects Work with Segmentation

Custom Objects don't just power campaign triggers—they make your segments dramatically more precise.

You can build segments like:

  • People related to any account where plan_type equals enterprise
  • People related to any account where health_score is less than 50
  • People where relationship attribute role equals admin AND account contract_end_date is within 90 days
  • People related to accounts where seats_active divided by seats_purchased is less than 0.3

These segments update dynamically as object attributes change. The moment an account's health_score is updated by your backend, every segment that references that attribute re-evaluates, and people move in or out of campaigns automatically.

This is the engine behind proactive churn prevention. Genesys Growth's 2026 analysis found that companies leveraging product usage data for behavioural targeting see 15% higher retention rates than those relying on relationship management alone. Custom Objects are what make that behavioural data actionable in your messaging layer.

For a deeper look at building complex segments in Customer.io, our advanced segmentation guide covers the full range of techniques—including how to layer object-based conditions with person-level and event-based conditions.


How Custom Objects Complement Your Event Schema

Custom Objects and events work together, not as substitutes for each other.

Events answer the question: what did this person do? Custom Objects answer the question: what is the current state of the world this person lives in?

A practical example: a user fires a feature_used event (event data). That event updates a counter on their account object: account.feature_uses_this_month increments by 1 (object data). If feature_uses_this_month drops to zero for the whole account, the account's health_score drops, and a campaign fires to the admin.

The event is the raw signal. The object is the aggregated, stateful context. You need both.

For a complete guide to designing your event schema for marketing purposes, see our article on event schema for marketing teams.


What B2B Marketers Get Wrong About Custom Objects

Mistake 1: Treating Objects as a Technical Problem

Custom Objects do require some engineering work to set up. But the mistake is letting that become an excuse to never use them. You don't need perfect, real-time data sync on day one. Start with a CSV import of your account data and one campaign. Prove the value. Then invest in the infrastructure.

Mistake 2: Modelling the CRM Instead of the Product

Your CRM probably has an Account object too. The temptation is to mirror your CRM structure exactly in Customer.io. Resist it. Your CRM account is designed for sales conversations. Your Customer.io account object should be designed for product and lifecycle messaging. That means carrying product usage data, health signals, and feature adoption metrics—not just company name and industry vertical.

Mistake 3: Sending to Everyone on the Account

Customer.io lets you send to every person related to an object when a trigger fires. That's powerful, but it requires judgment. Sending a renewal nudge to every user on a 50-person account is spam. Sending it to the billing contact and admin only is a targeted, valuable message. Always filter your audience using relationship attributes like role.

Mistake 4: Not Keeping Object Data Fresh

A health_score that was last updated three months ago is not a health score—it's a historical artefact. Object-triggered campaigns are only as good as the recency of the data feeding them. Build a regular sync process (Reverse ETL works well for this) that keeps account attributes current.

Mistake 5: Ignoring the 1,000-Person Limit

Customer.io won't create journeys for object-triggered campaigns that would affect more than 1,000 people at once. For most B2B SaaS accounts, this isn't an issue. But if you have large accounts with thousands of users, you need to filter your audience carefully—typically to admins or specific roles—to stay within this limit.


Custom Objects vs. Regular Person Attributes: When to Use Each

Signal Use Person Attribute Use Custom Object
User's first name
User's last login date
User's plan type (solo user)
Account's plan type (multi-seat)
Contract renewal date
Account health score
Number of seats purchased
User's role within an account ✅ (relationship attribute)
Feature usage event (single action) ✅ (event)
Cumulative feature usage (30-day aggregate)
User's email address
User's NPS score

The rule of thumb: if the data describes a single person independently of others, it belongs on the person profile. If it describes an entity multiple people relate to, it belongs on a Custom Object.


The Business Case: What Account-Level Messaging Actually Moves

Account-level messaging isn't just more sophisticated. It moves numbers that person-level messaging can't touch.

ABM research from Forrester and ITSMA consistently shows that account-based retention strategies drive 36% higher customer retention and 38% higher win rates compared to contact-level approaches alone. Vitally's churn benchmark data puts multi-year contract retention 40% higher than month-to-month, and proactive customer success (which Custom Objects directly enable) reduces churn by 20–30%.

For context, the average B2B SaaS company churns 3.5% of revenue monthly—roughly 35% annually. Enterprise accounts show dramatically lower churn (1–2% annually) precisely because those relationships are managed at the account level, not the individual user level.

The implication: if you're running a B2B or multi-seat SaaS product and you're managing messaging at the person level only, you're leaving the tools for your highest-leverage retention and expansion plays on the table.


How This Connects to Your Broader Lifecycle Strategy

Custom Objects aren't a standalone feature—they're an upgrade to your entire lifecycle stack.

  • Onboarding: new user sequences that know the account context from day one
  • Adoption: seat utilisation campaigns that push underused accounts toward value
  • Retention: health-score-triggered interventions before churn signals become churn
  • Expansion: renewal and upsell campaigns timed to contract milestones, sent to decision-makers
  • Win-back: account-level re-engagement when teams go collectively dark

Each of these stages benefits from account-level context. Without Custom Objects, you're running each stage in the dark, guessing at the account reality behind each individual user.

For a complete framework that maps these stages, our lifecycle email marketing guide covers the full journey from acquisition to advocacy, and our churn reduction playbook goes deep on the retention and win-back mechanics that Custom Objects make possible.


Getting Started: A Four-Week Implementation Plan

Week 1: Design Your Object Schema

  • Identify your two most critical object types (usually Account and Subscription for B2B SaaS)
  • List the attributes each object needs to carry
  • Define relationship attributes (especially role)
  • Map which systems own each attribute (product database, CRM, billing system)

Week 2: Seed Your Objects

  • Use CSV import to get your existing account data into Customer.io
  • Manually verify 5–10 accounts to confirm attributes are correct
  • Set relationships between existing people and their accounts

Week 3: Build Your First Object-Triggered Campaign

  • Start with the highest-impact, simplest campaign (usually the renewal nudge or the all-users-inactive win-back)
  • Build the trigger, audience filter, and email in Customer.io
  • Set it to draft mode and walk through test scenarios with real account data

Week 4: Connect the Sync

  • Work with your engineering team to set up real-time or scheduled API updates for key account attributes
  • Set up Reverse ETL if your account data lives in a warehouse
  • Activate your first campaign and monitor the first 30 days

Frequently Asked Questions

What are Customer.io Custom Objects?

Custom Objects are a data feature in Customer.io Journeys that lets you model non-person entities—like accounts, subscriptions, workspaces, or deals—and connect them to the people in your workspace. Once an object is connected to a person through a relationship, you can trigger campaigns based on changes to that object's attributes, and personalise messages with the object's data using Liquid.

How are Custom Objects different from person attributes?

Person attributes describe a single individual: their name, their plan, their last login. Custom Objects describe entities that multiple people share. An account object, for example, carries data about the whole account—health score, seats purchased, contract end date—and every person related to that account can access it in campaigns. The key difference is that a Custom Object can trigger messaging for an entire group of people at once, based on the state of one shared entity.

Can Custom Objects trigger campaigns for multiple people at once?

Yes. When an object attribute changes—say, an account's health_score drops below a threshold—Customer.io can send a campaign to every person related to that object, or to a filtered subset (for example, only people whose relationship attribute role equals admin). This is what enables account-level messaging: one trigger, coordinated outreach to the right people in that account. Note that campaigns are limited to audiences of up to 1,000 people per trigger event.

What data can I store on a Custom Object?

Any key-value attributes your business needs, up to 100kb total per object. Common examples for B2B SaaS include: plan type, MRR, contract end date, health score, seats purchased, seats active, last team activity date, CSM owner, and feature adoption scores. You can also store relationship attributes—data that lives on the link between a person and an object—like the user's role within the account.

How do I get account data into Customer.io?

There are four main methods: the Pipelines API (recommended for real-time updates), the Track API v2 (for programmatic object management), Reverse ETL integrations (for syncing from a data warehouse like Snowflake or BigQuery), and CSV import (for quick one-time seeding). Most production setups use a combination: Reverse ETL for account-level attributes that live in the warehouse, and the Track API for relationship changes that happen in the product in real time.

Can I personalise emails with Custom Object data using Liquid?

Yes. Customer.io exposes object attributes and relationship attributes in Liquid templates. You can reference account.name, account.contract_end_date, account.health_score, relationship.role, and any other attribute you've stored. This lets you write one email template that renders differently for every account and every user role, without any developer involvement at send time.

What's the difference between a Custom Object and a segment?

A segment is a dynamic group of people who share certain characteristics. A Custom Object is a data entity that people can be related to. They work together: you might create a segment of people related to any account where health_score is less than 50, then use that segment to trigger a campaign. The segment is the targeting mechanism. The Custom Object provides the data that powers the segment condition.

Can I use Custom Objects for one-to-many relationships?

Yes. A person can be related to multiple objects of the same type. For example, a consultant might be a member of three different client accounts. Each relationship can carry its own attributes—they might be an admin on one account and a viewer on another. Customer.io tracks each relationship separately, so you can trigger messaging based on changes to any one of those accounts and personalise the message with that specific account's context.

How do Custom Objects work with Customer.io's branching and multi-split features?

Within object-triggered campaigns, you can use true/false branches and multi-split branches based on object attributes or relationship attributes. For example, you could trigger a campaign when any account's plan_type is upgraded to enterprise, then branch users into different paths based on their role (relationship attribute): admins get a permissions walkthrough, managers get a reporting feature tour, and members get a quick-start guide. This lets one trigger produce highly contextualised experiences for every user type on the account.

Do Custom Objects work with all Customer.io message channels?

Yes. You can use Custom Object data and object-triggered campaigns across all channels: email, SMS, push notifications, in-app messages, and webhook-based integrations. This means your account-level health campaigns aren't limited to email. You can coordinate an account win-back across email, in-app, and push simultaneously, all driven by the same object-state trigger.

Is there a limit on how many Custom Object types I can create?

Customer.io doesn't publish a hard cap on object types. The first three types appear in the sidebar navigation under People; if you have more, they're nested under a Custom Objects folder. In practice, most B2B SaaS teams work with two to five object types: typically Account, Subscription, and optionally Workspace, Deal, or a product-specific type like Project or Class.

How does Customer.io handle it when a user belongs to multiple accounts?

Each relationship between a person and an account is tracked independently. So if a user is an admin on Account A and a member on Account B, Customer.io maintains two separate relationship records with different attributes. Campaigns triggered by changes to Account A's data will consider this user as they relate to Account A specifically, not their overall profile or their relationship to Account B.

Can I use Custom Objects for renewal campaigns even if my billing system is the source of truth?

Yes—and Reverse ETL is the recommended approach for this. You sync your Subscription object from your billing system (Stripe, Chargebee, etc.) to Customer.io on a regular interval. Fields like renewal_date, status, and plan_name stay current. Customer.io then uses those fields to power time-based renewal campaigns. You're not duplicating your billing logic; you're giving Customer.io read access to the commercial context it needs to send the right message at the right time.

What's the best first Custom Object campaign to build?

For most B2B SaaS teams, the highest-ROI starting point is a contract renewal campaign built on a Subscription or Account object with a contract_end_date attribute. It's a well-defined trigger (a specific date), a clear audience (billing contacts and admins), and a direct revenue impact (renewal). It also forces you to build the object infrastructure that unlocks everything else, making it an ideal foundation for your entire Custom Objects strategy.

How does this connect to Customer.io's Journeys feature?

Custom Objects are native to Customer.io Journeys. All the branching logic, wait-until blocks, time delays, and multi-channel coordination that Journeys provides applies to object-triggered campaigns. You can build sophisticated multi-step sequences—for example, a 90-day renewal campaign that sends an email at day 90, waits for a response, branches based on whether the admin clicked the renewal link, then sends an SMS follow-up at day 60 if they didn't—all driven by the account's contract_end_date. For a deeper guide to building these flows, our Customer.io Journeys guide covers the full automation architecture.


Wrapping Up

Five thousand years ago, Sumerian accountants in Uruk built the world's first written records to track one thing: the web of obligations and relationships that made commerce possible between people who might never meet face to face.

The problem they were solving is the same one you're solving now. Your B2B customers aren't isolated individuals. They're members of accounts, teams, and workspaces. They make decisions collectively. They churn collectively. They renew collectively.

Customer.io Custom Objects give you the infrastructure to model that reality—and then act on it with precisely targeted, perfectly timed messaging that reflects the actual state of each account, not just the recent behaviour of one user.

The Sumerians needed clay tablets and a stylus. You've got a much better toolkit.


Citations and Sources

  1. BBC News / Tim HarfordHow the world's first accountants counted on cuneiform — BBC World Service, 50 Things That Made the Modern Economy
  2. Library of CongressClay Tablets Reveal Accounting Answers — Cuneiform Tablets Collection
  3. Customer.io DocumentationObjects and relationships in campaigns — Updated March 2026
  4. Customer.io DocumentationObjects — Updated August 2025
  5. Customer.io DocumentationRelationships — Updated December 2025
  6. Alexandra Hubley / Customer.ioThe Marketer's Guide to Custom Objects
  7. Alexandra Hubley / Customer.io10 Powerful Use Cases for Custom Objects — September 2024
  8. VitallyB2B SaaS Churn Rate Benchmarks in 2025 — Ryan LaFlamme, April 2025
  9. Genesys GrowthB2B SaaS Churn Rates: 33 Statistics Every Marketing Leader Should Know in 2026 — Matteo Tittarelli, February 2026
  10. Revenue MemoAccount-Based Marketing Statistics for 2026: A Comprehensive Analysis — February 2026 (citing Forrester, ITSMA, ABM Leadership Alliance, Gartner, SiriusDecisions)
  11. Influ245 Account-Based Marketing Stats for 2026 (Research-Backed) — Anastasiia Khlystova, March 2026
David Crowther
Book a free consultation →

On our call, you'll be speaking with David Crowther, founder of NerveCentral.

Our initial consultation is not a sales call—you'll talk, I'll listen and ask questions—then I'll come back to you within 48 hours with our best ideas on how to grow your business.