You need campaign production management: a working view where the unit of work is the campaign, not the individual task and not the individual send. Task managers track who is doing what but don't model channel dependencies or approvals. Marketing automation platforms model the send, and they start after production is already finished. The work that goes wrong sits between those two tools: producing nine assets across four channels, checking them, putting them in front of the client, resolving what comes back, getting a decision, and knowing at any moment which piece is holding up the launch.
That space has a shape, and it is worth naming the stages before talking about tooling, because they are five different disciplines and agencies routinely run them as one:
client brief
→ journey design which campaigns and assets have to exist
→ agency production who builds each one, and its state
→ QA is it technically correct
→ client proof what does the client want changed
→ client approval who authorized which version
→ campaign sign-off is the whole set cleared
→ handoff the client sends it from their own platform
This article is the only one on the site that walks the whole path, so it links to all four pillars. Each stage has its own home: campaign journey design, campaign production management, client proofing and campaign approval software.
Why don't task lists and automation platforms cover this?
Most marketing software assumes one of two things.
Either the campaign is simple enough to run as a list of tasks, or it is complex enough to belong in a full automation platform.
A task list gets you assignments and due dates. What it can't tell you is that the landing page has to be approved before the paid social ads can finalize their call to action, or that the email can't go to seed testing until HTML production is complete. Those dependencies are real, they decide the launch date, and in a task list they exist only as a shared assumption between two people who both hope the other is tracking it.
An automation platform models the send: the audience, the trigger, the journey the recipient experiences. That is a different object from the campaign the agency is producing. By the time a campaign reaches the platform, the questions that consumed three weeks are already settled. Who at the client approved the 20% subject line. Which version of the hero image is final. Whether their legal contact signed off on the price claim. The platform holds none of that, because it was never asked to. That boundary, and where the sending platform fits in campaign production, is worth drawing explicitly before you pick tools for either side of it.
So the work happens in the gap, using whatever is available: a spreadsheet for status, email threads for approvals, Slack for the dependencies, and someone's memory for the rest.
What actually breaks between brief and launch?
Four failures show up in almost every agency running more than three client campaigns at once.
Status lives in people, not in a system. Once the brief is written, there's no reliable way to see where everything stands. You find out a piece is blocked the day before the deadline, not three days earlier when it actually became blocked. That is a campaign asset tracking problem before it is a tooling one: nothing holds an owner, a state and a blocker per asset.
Approvals turn into document archaeology. A client asks what was agreed on the email copy. Answering means searching a thread, finding the right PDF version, and hoping somebody took notes on the call. It takes an hour and the answer still is not certain.
Channel dependencies are invisible. They're understood by the two or three people closest to the work and written down nowhere. When one of those people is on holiday, the dependency stops existing.
Client proofing consumes account management time out of proportion to its value. Packaging the content, sharing it, tracking who has reviewed what, chasing the people who have not, collecting feedback from three different places, and then, separately, getting somebody to actually decide. None of that is the work. All of it is the job, and the two halves of it are proofing and approval.
If campaigns start from an ambiguous brief, all four get worse, because there is no agreed specification to track progress against.
What does a campaign canvas do differently?
The alternative to both tools is to model the campaign itself, visually, before production starts.
A campaign canvas maps the full structure: every piece of content, every channel, every dependency. Each node on the canvas is one deliverable, an email, a landing page, a paid social set, an SMS. Connecting the nodes puts the dependencies on the screen instead of in someone's head. The canvas becomes the thing the team looks at when they want to know what the campaign contains and what is waiting on what.
That map is only useful if production happens inside it rather than somewhere else. Which means each node carries four things:
- A brief for that specific piece, broken out by phase: creative, copy, production, QA.
- A pipeline, with phase-by-phase status, an assignee and a state per phase.
- Its own assets, with version history, organized by production phase.
- An approval workflow, including a way for a client to review without being handed the whole system. Our guide to defensible client approvals covers what an approval record has to capture to hold up later.
The other thing a canvas needs is somewhere to put the things that never make it into a formal brief. Free-form annotations, sitting on the structure itself rather than buried in a thread: briefing context, a decision made on a call, an open question flagged mid-production.
What does the client actually see?
One link, and only what concerns them.
When you share a node for review, the client gets the relevant version of the content, an interface for leaving feedback and approving, and nothing else. No internal status, no pipeline phases, no other campaigns, and no account to create. Guest links can be given an expiration date and revoked.
Their decision is captured in place: which version, which person, what time. Where a node needs more than one approver, the state is explicit, so "two of three approvers have signed off" is something you can read rather than reconstruct. That only stays true if those approvers review in parallel rather than in sequence. See how to cut campaign review rounds from four to one for why sequential review is what turns one round into four. The campaign reaches sign-off when every content node is done and the required approvals exist: the discipline of campaign approval software, applied to the whole campaign rather than one file at a time. That whole-campaign decision has its own checklist, separate from the asset rounds: what a campaign-level sign-off covers. Guest views carry your workspace branding, logo and colors, which matters more than it sounds like it should when the reviewer is your client's legal team.
What does that look like in practice?
That model is what the Journey Builder in LaunchSign is:
- Journey canvas with typed nodes: email, landing page, paid social, SMS, push, custom
- A production stage and one named owner per node
- Pin-based client feedback on the work itself, attached to the version it was left on
- Inbox previews across 100+ email environments, run by the agency before anything goes out
- Guest link generation with expiration and revocation
- Proofing rounds sealed against the version they opened on
- Multi-approver tracking per node
- Campaign-level sign-off gated on node completion
- Workspace branding on client-facing views
- Canvas annotations, internal by default, shareable per annotation
One boundary worth stating plainly, because it decides whether this is relevant to you. LaunchSign is not a sending platform and not a marketing automation platform. It sits between the brief and deployment, and it stops at sign-off. It hands off an approved, documented campaign. The platform the client already uses still sends it, and there is no connection between the two.
If you want to see the canvas and the per-node workflow in more detail, the product page walks through both.
FAQ
Is this a project management tool for marketing?
Partly, but the unit of work is different. A project management tool organizes tasks and assignees. Journey Builder organizes content: each node is a deliverable with its own brief, versions, and approval state, and the connections between nodes are production dependencies rather than task sequences. Agencies that run campaigns in a task manager usually keep it for the account layer and use the canvas for the campaign itself. If you're not ready to change tools yet, our guide on managing multi-channel campaign production covers how to get most of the benefit with what you already have.
Do clients need an account to review or approve?
No. Review and approval happen through a guest link. The link can be set to expire and can be revoked, and the client sees only the content shared with them, not internal status or other campaigns.
Does it connect to the platform the client sends from?
No, and that is deliberate. LaunchSign covers production, QA, client proofing and sign-off between the brief and deployment. The approved campaign is handed off to whatever the client already uses to send, by a person, not by an integration.
What size of agency is this for?
It earns its place once you are running several client campaigns at the same time, each with its own proofing cycle and its own named approver. For a single monthly newsletter approved by one person, a task list is enough.
What happens to the approval record after launch?
It stays attached to the campaign: version, approver, timestamp, per node. That's the artifact you go back to when someone asks in October what was agreed in July.


