Marketing automation review method: evidence records and reopening triggers

What should make me reopen the review?

Another review is warranted when a feature, edition, contract, subprocessor, data location or buyer requirement changes materially. Record the trigger against the affected claim and retain the earlier evidence state, rather than replacing it without a history; the review trigger should be traceable.

The reason to reopen is to check whether the changed condition affects the previous finding, not to erase what was known before. Keep the earlier record alongside any new evidence so readers can see what changed and whether the conclusion moved.

What decision can this review support?

It can help a buyer decide whether a platform merits testing, belongs on a conditional shortlist or should be rejected for the stated use case. It cannot establish that a product is right for every organisation, because the conclusion depends on the buyer case and the evidence gathered.

A supplier page records its maker's claims, not independent proof of how the software will perform for a particular buyer. Treat the result as bounded by its product, edition, evidence and review date, and do not present a supplier description as an observed outcome.

What has actually been checked so far?

At present, the work is a desk-research draft prepared on 5 September 2026 for organisations operating in England. It is not ready for publication until a named marketing-technology reviewer and qualified UK specialists approve it, so conclusions must stay limited.

No account, licence, integration, support case, contract, price, security control, accessibility path or outcome was examined. The work also received no affiliate funding, gifted access, sponsorship or supplier participation; the disclosure policy should make these boundaries clear before publication.

How do you decide which platforms enter the comparison?

A candidate needs a live first-party record and a plausible contracting route to qualify. Exclude any option that misses a mandatory buyer requirement or lacks evidence for testing; rank the remaining candidates only when buyer-specific weights and observed results justify an order.

Set out the buyer case before comparing suppliers. The audience brief should cover audiences, channels, data, users, integrations, volumes, service hours and exit needs, with every item labelled mandatory, weighted or contextual. The selection checklist can keep the task consistent.

Ask each candidate to complete the same buyer-defined task and return the same expected outputs. The HubSpot marketing automation page is a first-party account of its claims about workflow, branching and segmentation; those statements cannot establish how a particular edition, data set or team will perform.

Keep those statements labelled supplier-stated until the shared task produces direct observations against the expected result. That distinction prevents a supplier description from being mistaken for a test finding, while allowing the same claims to be checked against the same task and evidence rules.

How do you turn evidence into a defensible finding?

Use a record that separates evidence strength from confidence in the wording and labels supplier claims, contract facts, observed tests and editorial judgement separately. This makes the reasoning retraceable instead of letting an overall score conceal where the evidence is weak.

For each criterion, record the source URL, access date, product and edition, claim, evidence label, reviewer, finding, uncertainty and next action. The buyer must approve scoring weights before totals are shown; missing evidence remains unresolved, not an invented midpoint.

A mandatory failure outweighs the combined score, so a high total cannot cancel it. Use two passes: an analyst logs each claim without judgement, then a second reviewer checks whether the source supports the claim for its wording, product, edition, geography and date.

Keep screenshots as supporting material, retain the live URL and note when changing content or a login blocked verification. This lets readers distinguish a saved view from the page available on the access date, and judge the limits of what the recorded evidence can establish.

How can a test avoid misleading results?

Set the protocol before anyone receives access. Specify test data, user role, configuration, task, expected result, observation method and deletion step; these conditions make a run meaningful within the buyer case and let its outcome be compared with the intended result.

A failed run may reveal a setup problem rather than a product defect, so preserve the environment and invite a documented supplier response. Do not quietly repeat only unsuccessful runs until they pass; keep the initial finding beside any response in the same evidence record.

Which checks should stay outside the product score?

Keep data protection, security and accessibility in specialist gates outside the main product score. These checks define what must be examined, but a supplier statement or framework alone cannot show how a particular configuration behaves in the buyer's environment; qualified reviewers should define the scope and assess it.

ICO processor-contract guidance identifies subjects for a processing contract, but does not settle price, liability, support or termination. NCSC cloud security principles can organise security questions without certifying a product or local configuration; the security-risk framework is another reference for that review.

Use WCAG 2.2 to set the relevant scope across templates, forms and preference routes. A supplier conformance statement is not equivalent to buyer-observed evidence. Qualified reviewers should determine the scope, carry out accessibility checks and decide whether a gap is acceptable or rules out the candidate.

What should readers see before relying on the result?

Show enough context for readers to judge whether the finding applies: reviewers, dates, version, sources, tests completed, information unavailable and conflicts. State a bounded outcome, such as proceed to testing, conditional shortlist or stop for this use case, and explain the reasons.

Place a corrections route beside the result. A supplier clarification should not silently replace the earlier evidence state: date each amendment, identify the changed claim and explain whether the conclusion moved. Preserve the previous state so readers can trace the change and see which evidence prompted it.

What should I do first?

Start with the buyer case and shared task, then settle evidence rules before showing totals or giving suppliers access. Arrange specialist checks separately and keep a route for corrections; this sequence ties the decision to its use, makes unknowns visible and shows when the assessment should be reopened.