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 your team 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, a developer who owes a rendering fix. The external side is a single thing: the client owes a sign-off. Those are not the same kind of blocked, and only one of them is inside your control.
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.
How does this workflow differ for in-house teams?
In-house production is usually blocked by internal decision-makers rather than by an external client: legal, brand, the channel owner and a marketing director, each holding a different decision.
A normal state looks like this:
Email build complete
Legal claims approved
Brand one change open
CRM owner waiting to QA the revised version
Director final sign-off not started
Nobody here is late in the way an unresponsive client is late. Each of those five rows is somebody doing their job in sequence, and the campaign is still not ready. The coordination problem is knowing which of them is next and what they are waiting for, which is a different shape of problem from chasing one external decision, and it should not be modeled the same way.
When should a campaign be handed off for execution?
A campaign should move to execution when your organization's required production, QA, review 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 your 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 review 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 → review → sign-off
------------------- RELEASE BOUNDARY -------------------
CAMPAIGN EXECUTION
audience → schedule or trigger → delivery → reporting
Real platforms do work on both sides of that line, and the line moves depending on how your team 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 and client approval software for marketing teams, 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, review 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 where your team builds and sends them 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 your team 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 required QA done across all channels, review comments resolved or answered, those current versions approved by whoever owns each decision, and whatever final campaign-level sign-off your process requires. The specific list is set by your organization, and the useful part is that it exists in writing before the week of the send rather than being reconstructed during it.
