Campaign automation platform proposals: check PECR email permissions

A campaign automation platform proposal should show how email audiences are selected, how permission rules are applied and how opt-outs are respected. This guide gives you a practical way to review those points in the proposed platform and configuration, including the ICO’s explanation of the PECR soft opt-in. It focuses on evidence you can ask to see before accepting claims about how an automated email campaign will work.

Define the campaign and its audience

Begin with the intended campaign, rather than a general demonstration of platform features. Ask the supplier to describe who the emails are for, what triggers the campaign, what the messages are intended to do and when a contact should stop receiving them. If these details are undecided, record them as open questions; a platform recommendation cannot settle an audience decision that has not been made.

Ask the proposal to identify the recipient group in terms that can be checked. “Existing customers” or “engaged contacts” may be useful shorthand, but they do not explain how a person enters the audience or what information supports that decision. Request the actual eligibility criteria, including any relevant source, contact status or preference recorded for each person.

Clarify whether the proposal covers one defined email journey or a wider set of campaigns. If it covers several, ask for each audience and entry rule to be described separately. A broad statement that the platform supports segmentation does not show that the proposed audience rules match your particular campaign.

Also establish who is responsible for deciding which people may be contacted, who supplies the underlying records and who configures the rules in the platform. These may be different people or organisations. The proposal should name the hand-offs so a permission decision is not left implicit between your team, the agency and the software supplier.

Check the PECR route for the proposed emails

Ask the supplier to explain the basis on which the campaign’s recipients can receive the marketing email. Do not treat a contact being present in a database, a past interaction or a platform setting labelled “subscribed” as sufficient explanation. The review needs to connect the recipient group and the actual campaign to the applicable permission route.

The ICO says electronic marketing mail may be sent without an opt-in in a specific situation. The organisation must have collected the person’s details directly when they bought or expressed an interest in what it sells; the marketing must concern similar products or services; and the person must have been given a clear and easy way to opt out. Check the ICO soft opt-in conditions against the proposed audience and message. This is a limited route, not a general permission to email every contact in a customer or prospect database.

Ask the supplier to show how the proposal accounts for each condition where it relies on that route. For example, find out what record identifies how and when details were collected, how the system distinguishes the relevant products or services, and how an opt-out opportunity is presented. If the answer relies on assumptions about the records or campaign, mark those as dependencies that must be resolved before the audience is activated.

If the supplier says the campaign relies on consent or another applicable route instead, ask it to describe that route and the evidence it expects the organisation to provide. Avoid accepting a generic promise to “make the campaign compliant”. The proposal should make clear what it will configure and what information or decisions it needs from you.

The recipient and campaign context matter when applying PECR. If the proposal does not say what type of recipients it is addressing or which route it assumes, ask for clarification rather than applying the soft opt-in as a default. A wider overview is available in the UK marketing automation rules guide; for this review, keep the attention on the route the proposed email audience will actually use.

Trace the decision into platform rules

Once the audience and permission route are clear, ask to see how they become settings or rules in the proposed system. The supplier should identify the data fields, tags or other records used to determine eligibility and explain how those values affect entry into the campaign. A high-level diagram can help, but it should be possible to follow an individual example from its source record to the decision to include or exclude it.

Ask what happens when information is missing, contradictory or out of date. For example, a record might meet a general audience condition but lack the information needed to establish the route the campaign relies on. The proposal should say whether such a contact is held out for review, excluded or handled in another defined way; it should not silently treat unknown information as permission.

Where the proposal connects the platform to a CRM or another system, ask which information must pass between them, in which direction and how a failure will be noticed. The CRM integration questions can help frame that discussion. An integration logo or a claim that two products connect does not establish that the particular fields, updates and audience rules required for this campaign will work in your setup.

Request a demonstration or test using representative records. Include at least one record that should qualify, one that should not qualify, and one with incomplete or conflicting information. Ask the supplier to show the reason each record takes its path. This makes it easier to distinguish a real test of the proposed configuration from a demonstration of a generic platform feature.

Test opt-outs and suppression behaviour

Ask the supplier to explain how someone who opts out is prevented from receiving later marketing emails covered by the opt-out. The proposal should identify where that information is recorded, how the campaign checks it before sending, and what happens when the same person appears in more than one audience or system. The review should cover the interaction between an eligible audience and the exclusion rule, not just the presence of an unsubscribe link.

Use a test record to check the complete sequence: the person is initially eligible, opts out, and is then excluded from a later campaign. Ask what happens if the opt-out arrives through a different system or is recorded while a campaign is being prepared. Agree who checks the result and where evidence of the test will be kept.

Find out how changes to preferences are reflected in future campaigns. If the proposal depends on a scheduled data update or a manual process, ask the supplier to describe that dependency and how the team will know whether it has completed. Do not assume that changing a preference in one interface immediately changes every audience or journey connected to the platform.

Check the treatment of test sends and internal previews as well. A preview should not be confused with evidence that live exclusions work. The acceptance test should use a controlled test setup and show the relevant decision in the proposed configuration, without sending unintended marketing to real contacts.

Ask for evidence, ownership and limits

For every important claim in the proposal, ask what evidence supports it. A useful record might identify the claim, the demonstration or test provided, the result and any open issue. Keep a vendor statement about a general feature separate from proof that the feature has been configured and tested for your campaign.

Clarify who provides the records needed to establish the audience route and who checks that the records are suitable for the intended campaign. The platform or agency may be able to apply supplied rules, but that does not by itself resolve whether the source information or marketing decision is appropriate. Record the organisation or person responsible for each decision and for approving the audience before launch.

Ask what happens if a test fails or a required data field is unavailable. The proposal should identify who investigates, how a correction is agreed and whether the campaign remains paused until the issue is resolved. It should also distinguish a defect in agreed work from a later change to the audience or campaign brief.

Check what you will receive at handover. Depending on the agreed scope, this may include the audience definition, a description of the relevant platform rules, test results and instructions for reviewing or changing the campaign. Ask for the actual deliverables to be named rather than relying on general phrases such as “documentation” or “training”.

Use a repeatable review before approval

Before accepting the proposal, work through these checks and record the answer to each:

If an answer is missing, keep it visible as a condition or open question instead of treating it as a completed control. Ask the supplier to demonstrate the point, amend the proposal or identify whose decision is needed. A proposal that clearly separates what has been verified from what remains to be done is easier to assess than one that relies on broad assurances.

When comparing proposals, use the same campaign, audience assumptions and test cases for each. Compare what each supplier has actually shown: the rules it will configure, the exclusions it will test, the evidence it will provide and the responsibilities it expects your team to retain. This makes the review about the proposed platform setup and email controls, rather than an untested claim about what a product can do in general.

Close the review with a short written decision. Name the proposed platform, describe the campaign and permission route, list the controls demonstrated, and record any conditions that remain before launch. The result should make clear what is established, what is still an assumption and who must resolve each open point.