The joins between systems
A ticket buyer, a form respondent, a donor and a row in your books are four records for one human being. Here they are one, so there is nothing to reconcile and nothing to drift.
Tool sprawl
Nine tools, and not one of them knows who your customer is
Every tool you add is another copy of the same person, and keeping the copies in step is either manual work or an integration that quietly drifts. One account with many surfaces has no copies to keep in step.
- One account
- One customer record
- One sign-in
- One renewal date
The work that never appears on any invoice.
The sign-in sprawl
One identity opens contacts, events, payments, books, email, communities, analytics and the developer surface. Nobody on your side collects another password, and nobody gets locked out of one product.
The per-seat arithmetic
A paid plan raises the ceilings across every product at once and is a flat monthly price rather than a charge per person, so adding a teammate is a seat allowance rather than a multiplied bill.
The migration you keep postponing
Bring one job over, usually the one annoying you today, and leave the rest. The second job you move needs no setup, because it is already looking at the contacts the first one brought in.
The integrations you maintain
There is no connector to authorize, renew, or debug at the worst possible moment, because the products were never separate systems that needed introducing to each other.
The context you lose switching
Answering one question about one customer stops being a tour of four browser tabs. The history, the money, the event and the messages are on the same record.
Each of them is good at its job. None of them can agree with the others.
| Capability | Connections | Nine separate subscriptions |
|---|---|---|
| Does each individual job well | Yes | Yes |
| One identity across every job | Yes | No |
| One customer record across every job | Yes | No |
| No connectors to authorize and maintain | Yes | No |
| One renewal instead of nine | Yes | No |
| Flat pricing rather than per person, per tool | Yes | No |
| Self-service export of everything you put in | Yes | Limited |
Frequently asked questions
Which tools does a Connections account stand in for?
In practice: a scheduling link, an event ticketing platform, a CRM, an email sending plan, a website chat widget and helpdesk bot, a form builder, a community platform, a bookkeeping app, a marketplace listing account, a fundraising page, a crowdfunding platform, a site analytics product, a referral program tool, a transcription service, and an identity provider if you were about to buy one for your own product. Each of those is a separate subscription in a normal stack. Here they are surfaces on one account.
How should I compare this to what I already pay for?
Not on the invoice, and not because the invoice does not matter. Price comparisons between a bundle and a stack move every quarter as vendors reprice, so a number you check today settles nothing about next year. What does not move is the structural fact: several tools cannot agree on who a person is no matter how well each one is run, so the reconciliation work between them never goes away and never shows up as a line item anywhere. Compare on that first, then look at the plans.
What actually breaks in a stack of separate tools?
The joins. The ticket buyer in your event tool, the lead in your CRM, the donor on your fundraising page, and the row in your books are four records for one human being, and keeping them in step is either manual work or an integration that silently drifts. Every new tool adds another pair of records to reconcile, which is why the pain grows faster than the tool count does. One record with many surfaces has no joins to maintain.
Do I have to migrate everything at once?
No, and trying to would be a bad plan. The normal path is to bring one job over, usually the one that is annoying you today, and leave the rest where it is. Contacts import from CSV or vCard and keep their history from that point on. Because the products already sit on the account, the second job you move takes no setup at all: it is already looking at the contacts the first one brought in.
What if a specialist tool does one job better?
Then keep using it. Connections is built to be the place the work already lives rather than a demand that you abandon something that works. Public share links, embeddable checkout, a developer API, an MCP endpoint, and a full OAuth provider all exist so the account can sit beside whatever else you run. The consolidation argument is about the jobs that need to know about each other, not about owning every window on your screen.
Does one bill really cover every product?
Yes. A paid Pass plan raises limits across the whole account rather than unlocking a product, and it is a flat monthly price rather than a charge per person, so a second teammate on a workspace is a seat allowance rather than a doubled invoice. Money that moves through the platform is handled separately by take rates on the transaction, which is how ticketing, checkout, and crowdfunding pay for themselves whether or not you ever buy a plan.
What does the free base actually get me?
More than a trial, and it is not time-limited. Contacts are uncapped. Hosting an event is free including ticket tiers and check-in. Listing on the marketplace is free. Publishing a fundraising or crowdfunding campaign is free. Site analytics capture and dashboards are free on every plan. The developer MCP surface is unmetered to explore. Paid plans raise ceilings such as email volume, AI tokens, workspace count, team seats, notes kept, ledger transactions, and how far back analytics look.
Can I get my data out?
Yes, on your own, from My Account, as a zip of your profile, contacts, and event data. Developer Data Locker exports are always available. Connections makes money from people paying for software and from a cut of money that moves through the platform, and it does not sell the underlying records, so nothing about the design depends on your data being hard to remove.