Two tools aimed at the same job — lifecycle email for a software product — from opposite ends of the market. Customer.io is a platform you configure, with a monthly floor that assumes a funded company and a person whose job this is. Loops is a product that has already made most of the decisions, aimed at a SaaS team that wants lifecycle and transactional mail working by Friday. For most teams the price floor answers this before any feature comparison starts, and that is not a criticism of either one.
At a glance
| Customer.io | Loops | |
|---|---|---|
| What it is | Behavioral messaging and lifecycle automation | Product + marketing email for SaaS, priced per contact |
| Published pricing | Essentials $100/mo for 5,000 profiles, then $0.009 per additional profile — roughly $145 at 10K, $505 at 50K, and $955 at 100K. Premium starts at $1,000/mo. | Free at 1,000 contacts and 4,000 sends/mo. Paid plans price on subscribed contacts with unlimited sends — $49/mo in the 1K–5K band, $99/mo in the 5K–10K band, rising from there. |
| Best for | Behavioral lifecycle messaging a marketing team owns day to day. | SaaS teams who want lifecycle and transactional in one tool and never want to count sends again. |
| Watch out for | You pay per profile whether or not you ever message them, so signups you never email still raise the bill. | You pay for contacts, not sends, so a large dormant free list stays on the bill. It is a product rather than a primitive, with less low-level control than an email API. |
Prices are each vendor's published list prices, verified August 2026. Check the vendor's own page before you sign anything.
Where they actually differ
The floor filters the decision first
Customer.io
Customer.io's entry plan carries a monthly minimum that is a real line item for a small company, and the tier above it is an order of magnitude higher again. It is priced for an organisation with a growth team, and the price is coherent with the product: you are buying a platform that expects someone to own it full time.
Loops
Loops starts free at a small list and its paid bands begin at a number a bootstrapped SaaS pays without a conversation. That accessibility is not incidental to the design. The product is shaped around a team of a few people, at least one of whom writes code, and none of whom has lifecycle email as their entire job.
Transactional and lifecycle in one place
Customer.io
Customer.io can send transactional mail, and plenty of teams route password resets through it. It is not what the product is optimised for, and the surrounding machinery — profiles, workflows, segments — is heavier than a receipt needs. Many Customer.io customers keep a separate transactional provider, which means two vendors, two suppression lists and two sets of templates.
Loops
Loops treats transactional and lifecycle as one surface on purpose: the same template system, the same contact record, the same sending reputation. For a small SaaS that is a genuine reduction in moving parts, and it is the single most persuasive thing about the product. The catch is that it also couples them, so one vendor problem is now both kinds of mail.
How much a segment can express
Customer.io
Customer.io's segmentation reaches as far as your instrumentation does. Arbitrary events with arbitrary payloads, relative-time conditions, computed attributes, and segments that update continuously as behaviour arrives. If you can describe a cohort in English, you can almost certainly express it, and doing so is a genuinely technical task.
Loops
Loops keeps segmentation simple deliberately: contact properties, a smaller set of events, and straightforward filters. It covers the cohorts a small SaaS actually acts on — trialling, activated, churned, on a given plan — and it will not express something elaborate about behaviour over rolling windows. That is a real ceiling and also the reason it takes an afternoon rather than a quarter to get value from it.
Who operates it day to day
Customer.io
Customer.io rewards an owner. Someone has to define the event taxonomy, keep the workflows tidy, and understand why a journey stopped firing. In a company with a growth engineer or a lifecycle marketer, that ownership produces things a simpler tool could not. In a company without one, the platform decays into a handful of half-finished workflows nobody dares to touch.
Loops
Loops is designed for nobody owning it. A founder sets up the loops once, and the defaults are opinionated enough that the result is decent without curation. That is a real and underrated feature. It also caps the upside, because there is much less to tune even when tuning would pay.
What you pay for people you never message
Customer.io
Customer.io bills per profile above its plan allowance, counting everyone you have sent it whether or not any message ever went out. For a product with a generous free tier and low conversion, that is a bill driven by signups rather than by customers, and pruning is a deliberate maintenance task nobody schedules.
Loops
Loops bills on subscribed contacts with unlimited sending, which is the same trap wearing different clothes: a large dormant list stays on the invoice forever, and because sending is unlimited there is no volume dimension to optimise. The mitigation on both platforms is identical and equally unpopular, which is to delete people who are never coming back.
Writing the email
Customer.io
Customer.io gives you Liquid templating with the full profile and event payload in scope, a code editor, and reusable layouts. It is powerful and it is a developer's tool: getting a beautiful responsive email out of it is work you do, not work the product does for you.
Loops
Loops ships an editor whose output looks good without effort, which for a small team is worth more than templating power. The emails it produces have a recognisable house style, plain and typographic, and that suits a SaaS product announcement well. It suits a heavily designed brand campaign much less well, and there is no escape hatch into arbitrary HTML complexity.
What outgrowing each one looks like
Customer.io
You outgrow Customer.io upward, into its higher tier or into a data-warehouse-native stack, and by then the messaging logic is spread across dozens of workflows that encode years of decisions nobody wrote down. The migration is expensive because the tool was load-bearing, which is the price of it having been useful.
Loops
You outgrow Loops sideways, when a segment you need cannot be expressed or a flow needs to branch on something the product does not model. That arrives sooner than teams expect and it arrives gently: the tool keeps working for everything else while one important thing becomes impossible, and you start planning a move while still being reasonably happy.
Getting data in
Customer.io
Customer.io accepts identifies and events over its API, through the common analytics pipelines, and from a data warehouse, and the warehouse path is the one mature teams end up on because it makes the warehouse authoritative rather than the messaging tool. Setting that up is a project with a data engineer in it, and it is the difference between segmentation you trust and segmentation you argue about.
Loops
Loops takes contacts and events over a small API and through a handful of direct integrations, and the whole surface is designed to be wired up by one person in an afternoon. There is no warehouse sync to configure and no event taxonomy to design, which is exactly why it is fast to adopt and exactly why it cannot answer questions about behaviour it was never told about.
Pros and cons, side by side
Customer.io
Strengths
- The event history is retained and queryable, so a rule about what somebody did three times last fortnight is a segment rather than a feature request nobody can grant.
- Segments recompute continuously, so a person who cancels on Tuesday leaves the sequence on Tuesday rather than at whatever point it happens to end.
- Roles, approvals and a separate environment exist, which lets drafting and releasing be two actions carried out by two different people.
- Push, in-app and text are steps inside the same journey, so a nudge that goes unread in one channel can be followed by one in another without a second vendor.
Trade-offs
- The monthly floor assumes a funded company with somebody whose job this actually is, and the tier above it is an order of magnitude further away again.
- Its usefulness is bounded entirely by an event taxonomy your own engineers have to design, ship and then keep maintaining as the product changes.
- Every profile is billed whether or not a message ever reaches it, so a generous free tier converts signups directly into subscription cost.
- Left without an owner it fills with half-finished journeys that nobody understands well enough to be willing to delete.
Loops
Strengths
- Nothing has to be owned. The defaults are opinionated enough that a team with nobody responsible for email still ends up with something decent running.
- The price at the bottom is one a bootstrapped company pays without holding a meeting, which is frequently the difference between having lifecycle mail and having none.
- Product mail and campaigns share one surface, so there is a single place to look when somebody asks what a particular customer has been sent.
- Going from nothing to a working onboarding sequence takes an afternoon, and the absence of decisions to make is precisely the reason it does.
Trade-offs
- An event fires something and is not retained as a history, so any rule that needs to look backwards across weeks cannot be expressed at all.
- An audience is evaluated at the moment somebody presses send, so a person's state when the sequence began is the state the rest of it assumes.
- There is nowhere to exercise a journey that is not production, which makes testing properly and releasing the same action performed by the same person.
- There is one sending arrangement rather than several, so a brand or a traffic class that must not share standing has nowhere separate to be put.
Pick in thirty seconds
Choose Customer.io if
- Your lifecycle logic depends on behaviour only your application knows about, expressed over time windows rather than as simple flags.
- Someone will own this system — a growth engineer or a lifecycle marketer — and their time is better spent tuning than working around limits.
- You need journeys that call your own services and branch on the response, not just send messages.
- You are funded enough that the monthly floor is not the deciding factor.
Choose Loops if
- You are a small SaaS team and want lifecycle plus transactional mail working this week, from one vendor and one template system.
- Nobody is going to own the messaging platform, so opinionated defaults are worth more than configurability.
- Your cohorts are the ordinary ones — trialling, activated, churned, on a plan — and you do not need to express anything exotic.
- The price floor matters, because the alternative is not a cheaper platform but no lifecycle email at all.
What actually moves when you switch
In roughly the order you would do it. The expensive parts of an email migration are never the send call.
- Establish what an event is allowed to mean, because the two answers differ more than the word suggests. On a platform built around a retained stream, something you recorded last March is still queryable and a rule such as did this three times in a fortnight and then stopped is expressible. On a product that treats an event as a trigger, it fires something and is not a history anybody can interrogate afterwards. Every rule you have that reaches backwards through time is a rule that does not survive travelling in that direction.
- Check when each side decides who is in an audience, because one recomputes and the other freezes. A continuously evaluated segment adds and removes people while a sequence is still running; a filter evaluated at the moment somebody presses send captures a population and then mails it. The difference surfaces in exactly one place and it is a bad one — the person who unsubscribed, upgraded or cancelled between the click and the final message.
- Decide who finds out when the messaging stops happening, because a sequence that silently stops firing raises no error anywhere. The heavier platform offers metrics per step and the lighter one offers a campaign view, and neither of them will telephone anybody. The cheap remedy is a canary: one journey whose only job is to message a monitored address on a schedule, plus an alert when that message fails to arrive. Almost nobody builds it and almost everybody eventually wishes they had.
- Quote the instrumentation rather than the subscription, because that is where the cost of this migration actually sits. Travelling toward the programmable side means a taxonomy of events your application does not currently emit, designed by somebody who understands the product and the messaging, then shipped through your ordinary release process. Travelling away from it means all that work goes inert and the segments resting on it collapse into filters over properties. Either way the tool's price is the smaller number on the page.
- Write down which messages currently reach somebody by a route other than email, because only one side has any. Push, in-app and text each carry their own consent record, their own delivery semantics and their own way of failing, and a sequence that quietly falls back from one to another is doing something the replacement will not do. That fallback is usually a checkbox rather than code, which is why nobody remembers it exists until a ticket asks where the in-app nudge went.
- Find out where a journey can be exercised without production consequences, because on one side the answer is nowhere. A separate environment with its own data, its own keys and its own sending is a capability the heavier platform has, and a team migrating downward carries a habit — build it, test it properly, then release — into a place where testing and releasing are the same keystroke. Agree what caution replaces that environment before somebody demonstrates the need for one.
- Count how many sending identities you genuinely need, because one side treats that as configuration and the other as an assumption. Several brands, a staging domain and a distinct subdomain for bulk traffic are ordinary requirements, and a product designed around one company sending as itself may offer exactly one answer. If any of your mail must not share standing with the rest, confirm the destination can express that before the import rather than after the first complaint.
- Settle who is permitted to send to everybody, because the two distribute that ability very differently. A platform with roles, approvals and an environment keeps the person who drafts apart from the person who releases; a product designed so that nobody has to own it hands whoever is logged in the power to reach the whole list. That is a feature at four people and a liability at forty, and the transition between those two sizes happens without anybody noticing it did.
Questions to ask before you sign
Put these to a sales rep, or find the answer in the documentation before anyone quotes you a number.
- Does any rule we care about reach backwards through time, and could we express it using only the properties sitting on a contact?
- When somebody cancels midway through a sequence, do we need the remaining messages to stop, and would they actually?
- If our messaging silently stopped firing on a Friday, what would tell us, and how many days would that take?
- Which events does our application not emit yet, and whose backlog does adding them land on?
- Does anything reach our users by push, in-app or text message, and what is the plan for those on the other side?
- Where would somebody exercise a new journey before any real person receives anything from it?
- Who is allowed to send to the entire list today, and is that the same set of people we would deliberately choose?
Common questions
Can Loops handle transactional email properly?
Yes, and for a small SaaS it is one of the better arguments for the product: password resets and lifecycle mail share a template system, a contact record and a sending reputation. What you should think about is the coupling. If Loops has a bad day, both your marketing and your password resets have a bad day, and some teams deliberately keep those on separate vendors for that reason alone.
Is Customer.io overkill for a startup?
Usually, and the tell is not the feature list but whether anyone will own it. Customer.io produces excellent results for a team with a person whose job includes it and mediocre results for a team where it is everyone's fourth priority. If you cannot name the owner, the honest answer is that a simpler tool will outperform it in practice regardless of which is more capable on paper.
How do the bills compare as a list grows?
Both meter people rather than messages, so both grow with your database. Customer.io counts profiles above a plan allowance; Loops counts subscribed contacts in bands with unlimited sending. Loops is far cheaper at small and medium lists, which is its whole market. The gap narrows as the list grows, and neither rewards you for keeping dormant contacts around.
Can I use both, Loops for product mail and Customer.io for campaigns?
You can, and it is usually the wrong answer. Two tools sending to the same people means two suppression lists, two views of who is engaged, and two places a preference change has to land. If you are genuinely at the point of needing both, you have outgrown Loops and the cleaner move is to migrate rather than to straddle.
What does moving from Loops to Customer.io involve?
Contacts and properties export cleanly. Everything else is a rebuild: Loops flows do not map onto Customer.io workflows, the templates are a different system, and the events Customer.io wants are ones your application is probably not emitting yet. Budget for instrumentation work in your own codebase, because that, rather than anything inside either tool, is the long pole.
What should I instrument before evaluating either of them?
The handful of events that describe your activation path, and nothing else yet. Account created, the first action that signals genuine intent, the moment the product delivers its value, and whatever your churn signal looks like. Four well-defined events with stable names beat forty invented during a trial, because the ones invented during a trial encode whatever you happened to be measuring that month. Doing this first also makes the evaluation honest: with real events in place, both tools can be judged on whether they express the journeys you actually want.
Can I express 'did this three times in two weeks' on the simpler tool?
Generally not, and the reason is structural rather than a missing checkbox. A rule of that shape needs the events to be retained as a stream that can be counted and windowed after the fact. A product that treats an event as a trigger consumes it, does whatever it was configured to do, and does not keep a queryable record you can later ask questions of. So the cohort you want has to be computed somewhere that does hold the history — your own database, a warehouse, an analytics tool — and then pushed across as a plain property on the contact, which you keep refreshed on a schedule. That works and it is worth being honest about what it is: you have moved the interesting part of the segmentation into your own systems and reduced the messaging tool to a sender. Whether that is a sensible trade depends on how many such rules you have. At one or two it is fine. At a dozen you have rebuilt the expensive product badly.
What happens to somebody who cancels halfway through a sequence?
It depends entirely on whether the audience is recomputed or frozen, and this is the single most common way lifecycle email embarrasses a company. Where segments are evaluated continuously, the person leaves the moment their state changes and the remaining messages simply do not arrive. Where an audience is captured at the moment somebody presses send, the population is fixed and the rest of the sequence goes out regardless — which is how a customer who cancelled on Tuesday receives a message on Thursday explaining how to get more value from the plan they cancelled. If the product does not recompute, the mitigation is a check immediately before each send against your own current state, which means the sequencing tool is no longer the only thing deciding who gets the message. Write down which of your sequences would be actively embarrassing to continue, and treat those as the ones that need the check.
How would I know if my lifecycle emails stopped sending?
You would not, unless you arranged to. This is the failure mode nobody plans for because it produces no error: a trigger stops matching after a property is renamed, an integration key expires, somebody pauses a journey while investigating something and forgets to unpause it. Nothing throws, nothing alerts, and the metric that would show it — messages sent per day — is one nobody watches until revenue moves. The remedy costs an hour. Create one journey whose only job is to message an address you monitor on a fixed schedule, then alert when that message does not arrive. It catches an expired credential, a paused workflow and a broken trigger with the same probe, and it works identically on either product because it depends on nothing either of them offers. Put the alert somewhere a human is actually on call, not in an inbox.