The product in an email campaigner is everything except the send

Sending one email is a solved call. Sending a hundred thousand is the same call in a loop. So the instinct that an email campaigner is "the sending part" gets the product almost exactly backwards: the send is the piece you'll spend the least time on and own the least of. Join a CRM's contact data to an email service and a schedule and you've done a week of ordinary wiring. What turns that wiring into something a company pays for every month is three things sitting around the send — and the useful part of this exercise is that you own all three, which is the tell that this is a real product rather than a thin layer over a sending service.

One: the logic that decides who gets what

The value of a campaign isn't in the sending; it's in the deciding — which contact gets which message, and which contacts get nothing at all this time. That decision is a join between what the CRM knows (who someone is, what they've bought, where they sit in a pipeline, when they last engaged) and a set of rules about who a given message is genuinely for. A blast to everyone is a mailing list, and a mailing list is a commodity. A campaigner earns its keep by being good at segmentation — and segmentation is mostly subtraction, the discipline of not emailing the people a message isn't for.

That logic is yours. It's specific to how a particular business thinks about its particular customers, it's the thing that makes the difference between mail people are glad to get and mail they resent, and it's the part a competitor cannot acquire by reading your list of integrations. Two campaigners can wire up the identical CRM and the identical email provider and produce completely different products, and the entire difference is in the rules that decide who's in a segment and who's left out. The APIs are shared. The judgment isn't.

Two: the consent state, which you can never afford to lose

The second asset is the least glamorous and the most dangerous to get wrong: the record of consent. Who opted in, to what, and when; who unsubscribed and must never be contacted again. Part of this is plainly a legal requirement — GDPR, CAN-SPAM and their relatives make consent and a working opt-out non-negotiable — but the deeper point is ownership. Consent state is yours, and the email provider must never be the only place it lives.

Providers get swapped, plans lapse, accounts get suspended. If your suppression list — the people who explicitly said stop — exists only inside this quarter's sending service, then the day you migrate you risk mailing the exact people who told you not to. That's simultaneously the fastest route to legal trouble and the fastest route to destroying the third asset below. So you keep the consent record at home, in your own database, as the authoritative copy the sending provider is merely told about — the same move, for the same reason, as keeping a payment record that belongs to you and not only to the provider. The provider executes; the record of what people agreed to is yours to hold.

Three: deliverability, an asset you build slowly and break in a day

The third is the one founders discover late and painfully: getting email delivered is not the provider's problem to solve on your behalf. It's an asset called sender reputation, and you accumulate it. Mailbox providers decide whether your mail lands in the inbox or the spam folder based on how recipients have reacted to it over time — opens, replies, deletions, complaints. Send relevant mail to people who want it and the reputation compounds quietly in your favour. Blast irrelevant mail to a stale list and it can collapse, sometimes within a single bad campaign, and a collapsed reputation does not recover because you apologise.

So deliverability loops straight back to the first asset: good segmentation isn't only more effective, it's the thing that protects the channel itself. The product's quiet, ongoing job is to stop its own users from torching the reputation they depend on — a guardrail you build deliberately, not a setting the provider hands you. A campaigner that lets a customer mail everyone, always, is not a better product; it's one that helps its users destroy the asset they're paying it to protect.

What it rides, and the hard part

Underneath those three, the chain is foundation furniture: accounts, a scheduler for send timing, the email module itself — which keeps its own record of what was sent, separate from the provider's — the admin, and the log. None of that is the work. The three owned assets are the work, and the hard part is the market they sit in, because this is one of the most crowded categories in all of software. Mailchimp, HubSpot, and a hundred others have done exactly this for years, and done it well.

The verdict therefore has to take the crowd seriously rather than wish it away. As a general "send marketing email" tool, this is a red ocean, and the honest advice is don't. It becomes a defensible product the same way the others in this set do — by being specific. A campaigner built around a particular CRM's data model, or a particular industry's idea of what a good segment even is, where the join between customer data and message is domain knowledge the generalists flatten into a custom field, is a product with somewhere to stand. The send will never be your moat; anyone can send. The segmentation logic, wired to data the incumbents treat as an afterthought, can be.

The verdict

This is a full SaaS, and a mature one — which means the technology is the least of your worries and the market is the most. You own the three things that decide it: the logic of who gets what, the consent record that must outlive any provider, and the deliverability that good targeting protects. Build those well and the CRM and the email service are just inputs you plug in. Build them generically and you've walked into a crowded market carrying the one thing it has no shortage of. The foundation carries the accounts, scheduling, sending, and logging around the edges for exactly one reason: so the attention goes where the product actually is — the deciding, not the sending.