Why Contacts Alone Are Not Enough
In a multi-seat product, the unit that matters is rarely the person. The company starts the trial. The company picks a plan. The company hits the seat limit. The company churns. If your email platform only stores people, you end up copying company facts onto every contact and hoping they stay in sync.
That holds until it does not. A workspace upgrades to pro and suddenly you have five contacts to update. Two of them still carry the old plan because the loop failed halfway through. The trial-ending email goes to every seat, so the owner gets one copy and four teammates get a billing email about a decision they cannot make.
Organizations fix the shape of the data instead of patching the symptoms.
| What you want to express | Contact-only model | With Organizations |
|---|---|---|
| Acme is on pro with 12 seats | plan and seats copied onto every contact | one attribute set on the organization |
| The trial ends in 3 days | fires once per seat | one organization event delivered to owners |
| Only email people who can pay | tag guesswork | organization.role is owner |
| Every workspace over 5 seats | stale per-contact copies | organization.seats greater than 5 |
| Show the company name in the email | a custom attribute per contact | {{organization.name}} |
How Organizations Work
An organization is identified by your own externalId, so there is no mapping table to maintain. Upsert it whenever the org changes in your app:
{
"externalId": "org_123",
"name": "Acme",
"domain": "acme.com",
"attributes": { "plan": "pro", "seats": 5, "trialEndsAt": "2026-09-20" }
}
Contacts join with a role of owner, admin or member, and one contact can belong to several organizations, which is exactly what happens with agencies and consultants. Organization attributes reach every member, so organization.plan and organization.seats work in segments, sequence conditions and merge tags without a single per-contact write.
Events about the organization go to the organization rather than to a person, and you decide who hears about them:
{
"event": "trial_ending",
"properties": { "daysLeft": 3 },
"recipients": "owners"
}
recipients accepts owners (the default, falling back to admins when there is no owner), admins, all or none. Sequences trigger for exactly those people, and the event is recorded on the organization timeline either way, so you keep a full history even when you deliberately send nothing. Contact events can also carry an organization reference, which creates the membership automatically the first time you see a new teammate.
Start From Data You Already Have
If your events or contact attributes already carry a workspaceId, organizationId or teamId, Sequenzy finds it, previews the biggest organizations it would create, and names them from a matching name property or the work email domain their contacts share. No organization ID? When several contacts share a work email domain, the Organizations tab suggests an organization for it. Either way, nothing is sent and no sequences run.
With a payment integration connected, billing fills itself in. Paying contacts are filed under their organization, and it gets plan, mrr, ltv, billing_status, billing_interval and trial_ends_at attributes, so a segment on organization.billing_status reaches the whole team, not just the person who paid.
One Email Per Company, Everywhere You Work
To email a company once, choose Once per organization under the sequence's enrollment settings, then send the organization event with recipients: owners so the one email that goes out lands with the person who owns the plan. Personalize it with {{organization.name}} and {{organization.plan}}, and you have a trial-ending email that reads like it was written for that specific workspace.
In the dashboard, the Organizations tab lives inside Subscribers. Each organization has a page with its attributes, members and roles, who receives its events, and the event timeline, and every subscriber profile shows which organizations the person belongs to.
Organizations were called Accounts when they launched, and the developer surfaces keep that name. The REST API covers the full lifecycle under /api/v1/accounts, members and events. The CLI mirrors it with sequenzy accounts upsert, add-member and event, all supporting --json. MCP exposes the full set, including upsert_account, trigger_account_event and detect_account_organization_ids, so an agent can inspect and update organizations directly.
Organizations pair naturally with smart segments for company-level targeting, the automation builder for per-company sequences, the developer API for syncing, and the Stripe integration for the billing side of the same company. Organizations are included on every Sequenzy plan.