Vendor guide · E-commerce flows · verified pricing
Klaviyo Pricing Guide
The commerce retention engine — carts, catalogs, and repeat purchase, priced by profile band.
Klaviyo dominates commerce automation deservedly; SaaS teams should admire it from another aisle. Verify bands on the official Klaviyo pricing page.
Who this guide is for
This guide is for e-commerce operators, DTC marketers, and hybrid teams that run a real storefront alongside a product — and for the SaaS founder who keeps being told "just use Klaviyo" without anyone explaining why the recommendation fits a store but not a subscription app. You will find verified entry pricing, an honest map of what the automation engine does brilliantly, and the specific places where a commerce object model and a per-profile bill stop lining up with lifecycle work.
We assume retention revenue matters to you: repeat purchase, replenishment, browse-to-buy, and the email-and-SMS motion that carries it. If your "purchase" is a Stripe subscription rather than a cart, the convert and retain stages below will read differently — that gap is the whole reason this guide exists alongside our verified pricing snapshot.
Existing Klaviyo customers will also find the profile-hygiene and SMS-credit sections useful, because both quietly determine what you pay next quarter regardless of which campaign shipped this week.
And if you arrived from a vendor comparison that declared Klaviyo "best overall," read the object-model sections before switching anything. Best for commerce retention and best for subscription lifecycle are different claims, and only the first one has the receipts behind it.
What commerce money buys
Cart recovery, browse abandonment, back-in-stock alerts, and post-purchase cross-sells deploy in clicks with catalog data wired in and revenue attribution built in. Predictive models flag likely churners and high-value segments; benchmarks draw on millions of commerce senders. Stores should start on free, prove cart-recovery math, and scale as revenue per recipient justifies it.
What makes Klaviyo hard to displace is not the flow builder — several rivals ship similar canvases — but the join between event stream, catalog, and revenue reporting. When an abandoned-cart email brings back an order, the attribution closes without a data engineer wiring three systems together, and the same event history powers segmentation tomorrow.
Commerce flows in clicks
Carts, browse abandonment, welcome, post-purchase, and replenishment ship from templates that already understand product SKUs, discount logic, and inventory states.
Predictions and benchmarks
Likely-to-churn and high-LTV scores, plus category benchmarks, let a small team prioritize sends the way a larger retention org would with its own analyst.
Native revenue attribution
Every flow reports the dollars it influenced against catalog data, so the retention calendar can be defended in a budget meeting with numbers rather than anecdotes.
Multichannel timing
Email and SMS share one profile and one event history, so a cart reminder can fall to SMS when the inbox window closes — provided the credit pool and consent records are in order first.
None of this is free by accident. The depth above is exactly what the profile band is paying for, and the next section is about who should — and should not — foot that bill.
Why SaaS teams usually pass
Trials, seats, and dunning have no native objects; agent access is conventional-API shaped; profile-band pricing rewards list hygiene over the free-tier growth SaaS needs. Hybrid businesses with real storefronts can justify it, but subscription-only teams should plan extra integration work. Compare the axes in our verified pricing snapshot.
The deeper issue is vocabulary. Klaviyo thinks in products, carts, orders, and predicted lifetime value; a SaaS lifecycle thinks in trials, plans, invoices, seats, and failed payments. You can force one dialect into the other with custom events and property mapping, but every forced mapping is engineering you maintain forever — and the profile bill starts the day the import lands, whether or not those mappings are finished.
Hybrid storefront-plus-app companies are the exception worth naming: if cart revenue is real and the app is secondary, Klaviyo can own the store lifecycle while billing-triggered product mail lives elsewhere.
Decision shortcut: if the revenue event you most need to automate is an order confirmation, Klaviyo is home turf. If it is a trial expiring, a card declining, or a seat count changing, you are translating foreign objects into commerce-shaped ones — price that translation before you commit.
Pricing tiers and the billing axis
| Plan | Entry price | Billing basis | Reality check |
|---|---|---|---|
| Free | $0 | 250 active profiles; 500 emails per month | Enough to prove cart-recovery math on a small catalog before any commitment |
| From $20 per month | Active profile bands | The core channel; price moves as the profile base grows, not as sends grow | |
| Email + SMS | From around $35 per month | Profiles plus SMS credits | Bundle entry price only — SMS still draws from a separate credit pool |
| SMS credits | Billed separately from email | Expiring prepaid credit pool | Forecast separately; unused credits are a timing problem, not a rollover bonus |
Klaviyo bills on active profiles — people stored and tracked — which places it in the same family as per-contact pricing rather than per-send pricing. The profile axis punishes exactly the SaaS motion of keeping large free tiers, dormant trials, and long-tail signups in one system "just in case." Every profile you import sets a floor under your bill whether it converts this quarter or never opens an email again.
For commerce, the axis can be rational: a 40,000-profile base that returns measurable repeat-purchase revenue is paying for an asset. The discipline is keeping the base honest — suppressions, unsubscribes, and junk records should not linger as billable profiles — and rechecking band breakpoints whenever a list-growth campaign lands. Bands scale with profile count, so a successful referral spike can raise next month's invoice even when sends stay flat.
SMS deserves its own line in the model. Credits are prepaid and expire, which turns timing into money: a win-back blast that misses its window burns credits without a matching revenue line. Model email and SMS as two budgets that share a campaign calendar, and verify both against the official pricing page before launch, since credit rates move more often than profile bands.
Before every renewal conversation, pull three numbers: profiles in the band, emails sent last month, and attributed revenue per thousand profiles. If the third number is flat while the first climbs, you are subsidizing storage — the signal to clean the base or reconsider the axis, not to send more often into the same list.
Where it fits in the five-stage lifecycle
Commerce teams will recognize their entire calendar in those five cards: the stages map to how a store actually makes money. Welcome captures, nurture educates against catalog interest, convert recovers intent, retain drives the second and fifth orders, win back resurrects lapsed buyers. Flow templates exist for every card, and revenue reporting closes each loop.
For a pure SaaS product, the same five labels hide a mismatch. Welcome and nurture translate fine — people signed up and need onboarding mail either way. Convert breaks first: trial expiry and upgrade events are not orders, so they must arrive as custom events with properties your branches understand. Retain breaks second: product usage, seat expansion, and renewal timing have no commerce equivalent. Win back is recoverable only if you define churn decay yourself, because Klaviyo's predictions are trained on purchase behavior.
The practical pattern for hybrids is a clean boundary — commerce lifecycle here, billing lifecycle on a platform whose native events match subscription state — rather than one brittle event pipeline stretched across both.
Score each stage before you commit: if three or more of the five stages need custom instrumentation to function, you are paying commerce-platform prices for a subscription platform with extra steps.
Automation depth: what you can and cannot build
Klaviyo's builder is deep: multi-step flows, conditional splits, filters, event triggers, and segment entry criteria handle serious commerce logic without workarounds. The honest limits are not about node types — they are about which events exist natively and what the bill does while you model them.
Build freely
Cart and browse recovery, welcome and education tracks, post-purchase and replenishment, VIP and win-back, price-drop and back-in-stock, and any flow keyed to store events already in the catalog.
Build with engineering
Custom events for app activity, plan changes, or usage thresholds — instrumented through the API or server-side integrations, then maintained as a schema your flows silently depend on.
Out of reach natively
First-class trial countdowns, invoice retrial branches, seat-expansion triggers, and dunning sequences that distinguish a soft decline from a dead card without custom modeling on top.
Priced while you model
Every experiment against the profile band bills at full rate. Schema exploration and half-finished custom events do not pause the invoice the way a staging environment would elsewhere.
- The profile band prices stored people, not sends — growth marketing raises the bill before growth revenue arrives.
- SMS credits expire separately from email plans; a mistimed blast is a real cost, not a scheduling quirk.
- Predictive metrics and benchmarks assume commerce behavior; subscription cohorts will look wrong until retrained on your events.
- Deep custom-event work is possible but becomes owned infrastructure — plan for schema governance, not a one-off import.
- Bundle entry around $35 is a floor; serious SMS volume reopens the credit budget every campaign cycle.
Honest framing: for storefront retention, these limits rarely matter — the commerce object model is complete. They matter the moment a SaaS team tries to make billing events pretend to be purchases.
Where Klaviyo fits for SaaS teams
Klaviyo's commerce retention engine is not in question here — for cart, catalog, and repeat-purchase programs it sets the standard, and a storefront-heavy business should shortlist it first. Subscription-only teams should budget integration work for trial and billing states, then compare profile and SMS meters against their actual audience curve.
Common mistakes when adopting Klaviyo
- Importing every historical customer and lurker before checking the profile band. Profiles you barely mail still shape the price — clean the base before the first big sync.
- Buying the Email-plus-SMS bundle because the bundle sounds like a deal, then discovering SMS credits expire against a calendar your campaign plan ignores.
- Running pure SaaS lifecycle here because the brand is famous for email. Custom events can bridge the gap, but you will own that bridge forever while paying profile rates to do it.
- Benchmarking against commerce cohorts when your product is an app. Open rates and purchase-prediction scores trained on store traffic mislead on trial behavior.
- Skipping the free tier's proof window. Free covers 250 profiles and 500 emails — enough to validate cart recovery before any band step is rational.
- Letting suppression and junk records linger in the profile count. Hygiene is pricing hygiene on a profile axis; run it on a schedule, not after the invoice surprises you.
- Stretching one event pipeline across both storefront and billing lifecycles. When the mapping breaks during a failed-payment spike, both sides fail.
Klaviyo pricing FAQ
What does the Klaviyo free plan include?
250 active profiles and 500 emails per month as of the September 2026 snapshot. That is a real proving ground for a small catalog: build a welcome flow, switch on abandoned-cart recovery, and check whether attributed revenue justifies the first band step. It is not a lifecycle platform for a growing base — the send allowance and profile ceiling both close quickly once import begins.
Is SMS included in the Email plan?
No. Email starts from $20 per month; Email-plus-SMS bundles start from around $35, and SMS always draws from a separate prepaid credit pool that expires. Treat SMS as its own budget line with its own timing rules — bundle pricing is an entry point, not an all-you-can-send pass. Verify current credit rates on the official pricing page before promising a program to the business.
Can Klaviyo run trial nurture and failed-payment dunning?
Not natively in the way a subscription business needs. Klaviyo has no trial, invoice, or plan objects; you would instrument custom events for trial started, trial expiring, payment failed, and payment recovered, then branch on their properties. That is achievable with engineering effort and ongoing schema ownership — but it is translation work. Platforms with native Stripe, Paddle, or Lemon Squeezy triggers skip the translation entirely.
If you proceed anyway, treat the custom event schema as a published contract: document property names, freeze breaking changes, and alert when the producer stops emitting. Most dunning failures on custom pipelines are silent producer regressions, not branch-logic bugs.
How does profile pricing compare to per-send pricing?
Profile pricing charges for people stored; per-send pricing charges for mail actually delivered. A SaaS team with a large free tier and lean sending — the classic shape — tends to lose on profiles and win on per-send. A store with a moderate list and heavy campaign cadence can go either way. Model both axes against your own numbers in our verified pricing snapshot rather than comparing sticker prices.
The tie-breaker is volatility: if your signup rate swings month to month, per-send pricing converts that swing into a proportional bill, while profile pricing turns it into a ratchet — bands step up quickly and rarely step back on their own.
Should a hybrid store-plus-app company use Klaviyo for both?
Often for the store, rarely for the app — and splitting is normal. Commerce flows, predictions, and order attribution belong where the catalog lives; trial, billing, and dunning belong where subscription events are native. The failure mode to avoid is one overloaded event pipeline doing both jobs with no ownership boundary, which breaks precisely during billing incidents.
When does it make sense to leave Klaviyo?
When revenue per recipient no longer justifies the profile band, or when the product's lifecycle has become mostly subscription events you are permanently translating into commerce-shaped ones. Exit planning looks the same either way: clean export, consent fields intact, warmed sending path, and a dual-run window on critical flows.