Campaign production software coordinates the work that turns a brief into finished, checked and approved campaign assets: who owns what, which version is current, whether QA passed, and who signed it off. An ESP, or email service provider, is where the approved messaging is configured and executed: audience, schedule or trigger, delivery, and execution reporting.
The two are not competing categories. They cover different halves of the same campaign, and the boundary between them is the moment a campaign becomes release-ready.
What is campaign production software?
Campaign production software coordinates the work required to turn a campaign brief into reviewed, QA'd and approved assets that are ready for execution.
It is not a place to build audiences or schedule sends. Its job is to answer, at any moment, what state the campaign is in and who owes the next thing.
To do that it has to understand campaign-shaped objects rather than generic tasks: a campaign, its brief, each asset in it, an owner per asset, and a production, review, QA and approval state per asset. Take a real one:
Summer Sale, August
Email 01 Launch
SMS 01 Reminder
WhatsApp 01 Last chance
Landing page Offer
Four assets, one campaign. On any given Tuesday the email is at v6 with the client's approval, the SMS is at v2 waiting on copy, the WhatsApp message has passed QA, and the landing page is blocked on a legal comment. Four owners, four versions, four different states. A single row reading "Summer Sale in progress" describes none of it, which is the practical difference between a task and a campaign, and the reason campaign production management is a category rather than a spreadsheet column.
What is an ESP?
An ESP is the platform where messaging to recipients is configured and executed.
The acronym stands for email service provider, though most teams now run something broader: a marketing automation or customer engagement platform that also handles SMS, push, in-app and journey orchestration. Salesforce Marketing Cloud, Braze, HubSpot and Klaviyo are the names that come up most often in the teams we talk to.
Those four are not the same product. They differ in architecture, in the channels they cover, in how journeys are built, and in what adjacent work they support. Naming them here is not a comparison. It is a way of pointing at the execution side of the workflow, which looks roughly like this whatever platform you run:
approved campaign
→ audience and execution configuration
→ schedule or trigger
→ send and delivery
→ execution reporting
That is a real job, and it is a different job from getting four assets finished, checked and signed off in the first place.
What is the difference between campaign production software and an ESP?
The difference is which question each system exists to answer: production software answers "is this campaign ready", the execution platform answers "who gets it, when, and did it arrive".
Reading it as a set of operational questions is more useful than a feature list:
| Operational question | Campaign production software | Execution platform |
|---|---|---|
| What are we building, and which assets does it contain? | Holds the campaign scope, every asset named | Configured per message once the content exists |
| Who owns each asset right now? | One named owner per asset, visible | Outside the execution role |
| Is the copy written and the build finished? | Production state per asset | Content can live here; coordinating who owes what is a separate job |
| Which version is under review? | Review tied to a specific version | Varies by platform |
| Has pre-send QA been completed? | Coordinates readiness across every channel | Platforms have their own testing tools, with varying coverage |
| Who approved, and on which version? | The decision record | Approval capability varies by platform |
| Is the whole campaign ready to release? | The readiness decision | Receives the campaign once it is |
| Who should receive it? | Not the sending system | Audience and segmentation |
| When should it go out? | Not the sending system | Schedule or trigger |
| Does it deliver the message? | No | Yes |
The right-hand column is deliberately cautious. Execution platforms do carry content, previews, collaboration features and approval steps to different degrees, and the mix changes release by release. The distinction that holds is the primary operational job, not a claim about which buttons exist.
What work should happen before a campaign enters the ESP?
Pre-execution campaign production is everything that has to be true before a campaign is worth configuring for delivery.
Ten steps, though real teams reorder several of them:
- The brief is approved for production.
- Every asset in the campaign is identified, including the ones nobody has started.
- Each asset has one named owner.
- Copy is produced.
- Design and build are completed.
- Pre-send QA is completed across all channels.
- Review comments are resolved or answered.
- The current versions are approved.
- Campaign-level readiness is confirmed across the set.
- The approved campaign is handed to execution.
The order is not the point, and neither is the number. Plenty of teams build the email inside the sending platform from step four onward, which is fine. The point is that "put it in the ESP" is not a substitute for steps one through nine, and a campaign that skips them arrives at the sending platform with its coordination problems intact. The sequencing, and who owns each handoff, is the subject of how to manage a campaign from brief to sign-off.
Why isn't the ESP enough to manage campaign production?
An execution platform can be entirely capable and a campaign can still be uncoordinated, because the two things are measured differently.
The build existing is not the same as the campaign being ready.
A marketing manager looking at a finished email inside their sending platform still cannot answer, from that screen:
- Is the SMS ready?
- Is the landing page on the same version of the offer?
- Has legal finished reviewing the terms?
- Did the client approve this version of the email, or the previous one?
- Was the Outlook rendering issue fixed, and by whom?
- Who owns the one remaining change?
- Is the campaign, as a set, ready to go?
Here is what that looks like on a real week:
Black Friday
Email v6 approved
SMS v3 waiting on copy
Landing page v8 legal change requested
WhatsApp v2 QA complete
The email may already be built and sitting in the sending platform, correctly. The campaign is not production-complete, and nothing about the email's presence there changes that. Keeping those four rows visible in one place is the whole of what it means to manage multichannel campaign production.
Does campaign production software replace Salesforce Marketing Cloud, Braze, HubSpot or Klaviyo?
No. Campaign production software does not replace the execution role of any sending platform, and a team that adopts one still needs the other.
Campaign production software
→ gets the campaign organized, reviewed, checked and signed off
Execution platform
→ configures and delivers the approved messaging
Concretely, a production tool does not send email, SMS or WhatsApp messages, does not schedule or trigger delivery, and does not build audiences. Adopting one migrates nothing out of Salesforce Marketing Cloud, Braze, HubSpot or Klaviyo, and it should not ask you to. Execution stays exactly where it is, which is the point: the two halves solve different problems, so swapping one for the other just leaves a hole where the other used to be.
Should campaign approval happen inside the ESP?
Approval should be designed around the version and the decision, not around whichever application happens to hold the final build.
Where the approval physically lives matters less than whether it is traceable.
The test is whether the agency can answer five questions about any campaign that shipped last quarter:
- Who approved it?
- What were they responsible for approving?
- Which version did they approve?
- When?
- Did anything change afterward?
If your current process answers all five reliably, the location is a detail. Most do not, and the reason is structural rather than a failing of any platform: approvals get given in the channel where the request happened, which is usually email or chat, and the build lives somewhere else. That is the gap a campaign approval process is meant to close.
There is also a sequencing argument for settling sign-off before execution. Once a campaign is configured for delivery, an approval question becomes a scheduling problem, and the fifth question is the one that bites: what happens when a campaign changes after approval is much harder to answer well when the change lands on the version that is already queued.
Where does pre-send QA fit?
Pre-send QA is the verification done before a campaign is released for execution, and it belongs to production rather than to sending.
It covers the checks that only make sense across the finished set:
- Links resolve to the intended pages, with the intended tracking
- Personalization fallbacks behave when the field is empty
- Rendering holds across the clients your list actually uses
- Dark mode does not break the layout or hide text
- The offer reads identically in every asset that states it
- The dates agree across channels, including relative phrasing
- The assets do not contradict each other
Some of that can be done inside a sending platform, and platforms provide their own testing tools. What sits outside any single one of them is the cross-channel half: an email test tells you nothing about whether the SMS and the landing page agree with it. The full list, organized by channel, is the campaign pre-send checklist.
What is the difference between campaign production software and project management software?
Project management software models tasks and projects; campaign production software models campaigns, assets, versions and decisions.
The difference shows up the moment somebody asks for status.
A project tool gives you this:
Build Summer Sale campaign In progress Due 14 Aug
Campaign production state gives you this:
Summer Sale
Email copy approved, build complete, one QA issue open
SMS copy in review
Landing page waiting on legal
Campaign sign-off blocked
Both are true. Only the second tells you what to do next, and who to ask. A general project tool can be bent into the second shape with enough custom fields and discipline, and plenty of teams do exactly that; where that approach holds and where it breaks is covered in using Asana or Monday.com for campaign work.
How does this workflow differ for agencies?
Agency production is blocked from two directions at once: internal work the team owes, and decisions the client owes.
Flattening both into "In progress" is what makes agency status meetings so slow.
The internal side is a copywriter who owes a revision, a designer who owes creative, an email developer who owes a rendering fix. The external side is two things, and they are not the same: the client owes comments, or the client owes a decision. Neither is inside the agency's control, and confusing them is how "waiting on the client" becomes a status that means nothing.
The question an account manager needs answered before every status call is exactly one sentence long: are we waiting on us, or waiting on the client? A production view that cannot answer it in a glance is a view that will be re-derived by hand, over Slack, every Monday.
What happens when the client spreads the decision across several people?
Most clients do. The campaign is then blocked by a chain rather than by one contact, and a normal state looks like this:
Email build complete (agency)
Client legal claims approved
Client brand one change open
Client marketing waiting to review the revised version
Client approver final sign-off not started
Nobody here is late in the way an unresponsive client is late. Each of those rows is somebody doing their job in sequence, and the campaign is still not ready. Two of them are also different kinds of pending: the open brand change is client proofing, and the missing sign-off is client approval. A production view that files both under "with client" cannot tell an account manager which one to chase.
When should a campaign be handed off for execution?
A campaign should move to execution when the agency's production and QA conditions and the client's proofing and sign-off conditions are all satisfied for the current versions.
There is no universal rule for that list, and any article claiming one is guessing at the client's compliance requirements.
What is portable is the set of questions a release-ready campaign makes answerable:
- What are the current assets, and what version is each one on?
- Is every required asset complete?
- Has the required QA been done?
- Are the client's proofing comments resolved or explicitly answered?
- Are those current versions approved?
- Is campaign-level sign-off complete?
- Who owns execution from here?
The boundary itself is worth drawing, because most of the confusion in this category comes from teams not having drawn it:
CAMPAIGN PRODUCTION brief → assets → production → QA
CLIENT PROOFING proof → comments → clean version
CLIENT APPROVAL decision → campaign sign-off
------------------- RELEASE BOUNDARY -------------------
CAMPAIGN EXECUTION audience → schedule or trigger → delivery → reporting
Campaign production is the first band only. Proofing and approval are separate disciplines that happen before the release boundary, and lumping all three under "campaign production software" is the definitional shortcut that makes this category hard to compare. One product can span several bands, as LaunchSign does; the categories are still distinct.
Real platforms do work on both sides of the release boundary, and the line moves depending on how the client builds. It is an operating-model distinction, not a claim that the software categories have rigid borders.
Where does LaunchSign fit between the brief and the ESP?
LaunchSign is campaign production, client proofing and approval software for marketing agencies, covering the span from brief to sign-off.
It holds the campaign as a visual journey with its brief, its email, SMS, WhatsApp and landing page assets, a production workflow and owner per asset, inbox previews across 100+ email clients, proofing rounds bound to a specific version, client review with no account to create, and the approval history behind the final campaign sign-off.
It sits between the brief and the ESP, and it stops there:
Plan → LaunchSign coordinates production → QA → review → sign-off → your platform executes
LaunchSign does not send. It does not replace Salesforce Marketing Cloud, Braze, HubSpot, Klaviyo or any other execution platform, and it does not integrate with them. Emails are still built and sent in the platform the client already uses today, and nothing about the final delivery step moves.
That boundary is deliberate rather than a gap waiting to be filled. The work of getting a campaign ready is coordination, review and decisions, and it is a different problem from delivery. Teams that separate the two tend to find their sending platform gets simpler to use, because it stops being asked to double as the status board.
FAQ
Does campaign production software replace an ESP?
No. Campaign production software coordinates the work required to prepare and approve a campaign: briefs, assets, owners, versions, QA, review and sign-off. The ESP or customer engagement platform performs the execution role, which covers audience, scheduling or triggering, delivery and execution reporting. A team using both keeps its sending platform exactly as it is.
Do I need campaign production software if I already use Braze or Salesforce Marketing Cloud?
It depends on whether the agency already has a reliable way to answer who owns each asset, which version is current, whether QA is done, and who approved what. If that lives in a shared spreadsheet, a chat channel and somebody's memory, the gap is coordination rather than execution, and adding platform features will not close it. If your process already answers those questions, you have solved the problem some other way.
Should campaign approval happen before the campaign enters the ESP?
Teams structure this differently, and building inside the sending platform first is a legitimate way to work. What matters is that there is a reliable point at which the current state of the campaign receives sign-off, and that the record says which version it applied to. The failure mode is not building in the wrong order, it is having no moment where anyone can say the campaign is approved and point at what.
Is campaign production software the same as project management software?
No. Project management software models tasks, assignees and due dates across any kind of work. Campaign production software models campaign-specific objects: assets per channel, versions, review rounds, QA state and approval decisions. The practical difference is that one tells you a campaign is in progress and the other tells you the SMS is waiting on copy while legal holds the landing page.
What should be complete before a campaign is sent?
Every required asset finished at a known version, the agency's QA done across all channels, the client's proofing comments resolved or answered, those current versions approved by whoever at the client owns each decision, and whatever final campaign-level sign-off the account requires. The specific list is set with the client, and the useful part is that it exists in writing before the week of the send rather than being reconstructed during it.
