How do you centralize campaign feedback from email, Slack and other tools?

Give every campaign asset one review location, one current version, and one recorded decision. Email and Slack are good at telling someone that a thing needs attention; they are bad at holding the thing itself, because a comment separated from the version it describes stops being usable within about a week. The goal is not to remove Slack or email from the process. It is to stop either of them becoming the system of record for what was reviewed and what was approved.

Why does campaign feedback get lost?

Take a Summer Sale campaign with three assets in production:

• summer-sale-email-v3.html
• summer-sale-sms-v2.txt
• summer-sale-landing-v5

Plus the two strings that never live in a file: the subject line, 20% off ends Sunday, and the preheader, Your weekend offer is here.

Now add the feedback, which arrives over two days from four directions. Account manager Clara Ndiaye forwards the client's comments by email. Designer Tomás Rivera gets a Slack DM asking for a different CTA. Marketing director Sofia Marchetti marks up a PDF and sends it back as an attachment. Legal counsel Priya Raman approves the promotional wording inside a thread that also contains next quarter's budget.

Four channels is not the problem. Plenty of good campaigns are discussed in four places. The problem is that four basic questions now require a person who was present in all four conversations:

1. Which asset does this comment refer to?
2. Which version was in front of the reviewer when they wrote it?
3. Was the comment resolved, and how?
4. Was the version that eventually shipped actually approved?

Three assets, five people, four channels, and nobody can answer those in under ten minutes without reading somebody else's inbox. A centralized process makes the answers part of the campaign record instead of part of a search history.

What campaign feedback should be centralized?

Centralizing it does not mean forcing every conversation into one thread. It means that seven things stay attached to the work they affect, and that the record survives after the people involved have moved on to the next campaign.

That last row is the reason campaign approval software exists as a category separate from proofing tools. Collecting comments is the easy half. Knowing which version reached a decision, and who made it, is the half that gets asked about later.

How do you keep feedback attached to the correct version?

A comment like "change the CTA to Shop the sale" is incomplete on its own. Written against summer-sale-email-v2, it should stay part of the history of v2 once v3 exists, and v3 should start its own review rather than inheriting v2's.

The sequence that works is boring and has seven steps:

1. summer-sale-email-v2 goes into review.
2. The client asks for the CTA change.
3. The request stays attached to v2.
4. Production builds v3.
5. V3 becomes the current review version.
6. The client reviews v3.
7. The approval is recorded against v3.

The step teams skip is the third one. Overwriting v2's history when v3 appears feels like tidying, and it deletes the only evidence of why the change was made. Answering which campaign version was approved months later depends entirely on that history staying additive.

This is why "the client approved the email" is not a usable sentence. The usable version names a revision: the client approved v3, on 6 August, after the CTA change. The same gap widens across a multichannel campaign, where an approved email says nothing about the SMS or the landing page it ships alongside. That distinction between an asset decision and a campaign decision is what campaign-level approval means, and it is the one most teams discover the hard way.

How should agencies centralize client feedback?

On a live campaign there might be four open items at once. The copywriter owes a subject-line revision. Tomás owes a hero-image change. The developer owes an Outlook rendering fix. And the client owes a decision on the promotional terms.

Three of those are production. One is an external blocker that no amount of internal effort clears. If all four sit as messages in a Slack channel, Clara has to reconstruct the conversation before she can answer the only question the client will actually ask on Thursday: what are you waiting on from us?

For every client-facing asset, the record needs seven fields:

Email still works for telling the client the revised email is ready. Slack still works for telling Tomás there is one open comment on the hero image. Neither should be the only place the decision exists, because both are private to whoever was in the thread and neither survives the account manager going on holiday.

How should in-house teams centralize campaign feedback?

A regulated promotion might need four reviewers with four different scopes: legal counsel on the promotional terms, a brand lead on language and imagery, a CRM manager on implementation, and a marketing director for the final call. A thumbs-up from the director does not resolve legal's outstanding comment, and legal writing "wording looks fine" does not approve the campaign.

Flattening that into one status called Approved loses the information that matters:

Four rows instead of one field. When someone asks in October who cleared the exclusions on the Summer Sale email, that table answers it and a single status does not.

How do you separate comments from actual approval?

Comments and sign-off should therefore be different actions with different statuses. Five states cover almost every campaign:

1. Draft. Production is still in progress and nobody should be reviewing yet.
2. In review. Reviewers can comment against a specific version.
3. Changes requested. At least one change is open and has to be resolved.
4. Ready for sign-off. The requested changes are done and the current version is waiting on a decision.
5. Approved. An authorized reviewer signed off on the current version.

"Looks good." "Much better." "Fine by me." "Thanks." Four phrases that arrive constantly and mean nothing in a dispute, because none of them answers who approved, what they approved, which version they saw, when they said it, and whether the approval survived the two edits that came afterwards. Those five questions are also the shape of a campaign approval audit trail, which is what you are left holding when something wrong reaches the inbox.

How do you stop screenshots and PDFs becoming the review surface?

The failure runs like this. email-v3.pdf goes to the client on Monday morning. The client comments on page 1. The agency updates the live email that afternoon. On Tuesday a second reviewer opens the same PDF from their inbox and comments on copy that changed eighteen hours earlier. The attachment is now a parallel version of the campaign with its own review thread.

Static files are still useful as a record or an attachment. The trouble starts when the attachment becomes the review environment while the real asset keeps moving somewhere else. The rule is one line: review the current version, not a representation of a version that may already be stale.

For email specifically, the review surface should also be close enough to the produced asset that a reviewer is not approving a picture of an email whose links, copy or dark-mode rendering differ from what will actually send.

What should a centralized feedback workflow look like?

Steps 5 and 7 are the ones that get dropped under deadline. A comment does not stop existing because a new version was uploaded, so every request needs either a change or a stated reason there was none. And sign-off has to be asked for, not inferred: a resolved comment thread means the conversation finished, not that anyone authorized the send.

Slack and email keep their jobs in this workflow. They are how people find out that something is waiting on them. What changes is that the campaign record, not the notification, is the thing you go back to.

Where does LaunchSign fit into centralized campaign feedback?

The assets, their production status, the review activity and the approval history live in the same campaign context, so an email, an SMS, a WhatsApp message and a landing page are parts of one campaign rather than four unrelated approval threads. Each review round is bound to a version that is sealed when the round opens, comments are anchored to that version and carry their own resolved state, and verdicts are recorded with a name and a timestamp rather than edited into a status field. Clients review and sign off from a link without creating an account, which matters when the person who owes the decision does not work for you.

The boundary is deliberate, and it is the reason the record stays clean: LaunchSign does not send. Execution stays in Salesforce Marketing Cloud, Braze, HubSpot, Klaviyo or whatever your team already uses. The campaign is planned, produced, checked, reviewed and signed off first.

How do you know whether campaign feedback is truly centralized?

Eight questions make a fair test:

• What is the current version of each asset?
• Which comments are still open?
• Which requested changes were resolved, and how?
• Who owes the next action?
• Which assets are waiting for review?
• Which assets are waiting for sign-off?
• Who approved the final version?
• Did anything change after that approval?

Run it on a campaign that shipped three months ago. If the answers take a search of #campaign-launch, three email threads, a PDF attachment and a message to whoever ran the account, the feedback was never centralized. It was discussed in several places, which is a different thing and reads identically until the day somebody asks.

FAQ