Outlook
Reputation management in England: CMA guidance and a software checklist
Use named CMA fake-review guidance and Amazon and Google commitments to build an England review-software checklist for evidence, reporting and decisions.
For reputation management in England, build a review-software buying brief around publication duties, platform commitments and demonstrable case handling. Keep those categories separate. Use the Competition and Markets Authority (CMA) guidance to define the work, then ask suppliers to prove how their software supports it.
Name the publication duty
The "Short guide for businesses: publishing consumer reviews and complying with consumer protection law" says publishers need reasonable and proportionate steps to prevent and remove fake reviews, concealed incentivised reviews and false or misleading consumer review information. Make this a workflow requirement.
The law on fake reviews applies to all traders who publish consumer reviews or consumer review information. Fake reviews are explicitly banned under the Digital Markets, Competition and Consumers Act 2024. CMA207, "Unfair commercial practices", is guidance on the Act's protection from unfair trading provisions.
What is reasonable depends on the circumstances of each case and what is proportionate to preventing and removing banned material. Record the review, concern, evidence and decision together. Use a disclosure policy to make incentives and the reasons for publication decisions visible to whoever approves the case.
Use the named Online reviews case record
The CMA's Online reviews case record includes Amazon's undertakings to enhance its systems for tackling fake reviews and catalogue abuse, published on 6 June 2025. Use this dated commitment as a testing prompt, not as evidence that a review-software supplier offers matching functions.
On 25 June 2021, the CMA opened formal enforcement cases against Amazon and Google in relation to possible breaches of consumer protection law. Keep an investigation separate from a finding when designing a case record. Opening a case does not necessarily mean the CMA has found a breach.
For software planning, distinguish the event recorded from the action your team must take. Ask whether staff can label a concern as unverified, attach supporting evidence and document an investigation outcome. Do not let a demonstration treat every incoming report as confirmation that a review is fake.
Translate Amazon and Google commitments into tests
Amazon committed to processes to quickly detect and remove fake reviews and catalogue abuse, and to clear mechanisms through which consumers and businesses can report them. Its undertakings cover reviews, review counts and star ratings for products listed on and visible to consumers searching its UK online store.
Google agreed to sanction UK businesses that boost star ratings with fake reviews and to place warning alerts on their profiles. It also committed to deleting reviews from repeat posters of fake or misleading reviews for UK businesses and banning those individuals from posting new reviews, regardless of location.
| Documented platform commitment | Review-software demonstration question |
|---|---|
| Amazon: detect and remove fake reviews and catalogue abuse. | Can staff connect a concern, investigation and recorded action within the same case? |
| Amazon: reporting mechanisms for consumers and businesses. | Can staff retain the report and distinguish it from the review being challenged? |
| Google: warning alerts on profiles of UK businesses using fake reviews to boost star ratings. | Can staff record an alert, its context and the follow-up decision? |
| Google: delete reviews and ban repeat fake or misleading reviewers. | Can staff distinguish action concerning a review from action concerning a reviewer? |
For fake Google reviews, test the record-handling task rather than promising a removal outcome. Ask the demonstrator to show an unresolved concern as well as a completed case. Do not label a review fake solely because it is negative, and keep the reason for any proposed action visible.
A checklist for the software demonstration
Map the team's operating workflow before testing features. Identify who receives a concern, who investigates it and who approves a publication decision. Use fictional review content for the demonstration, and ask the supplier to show the complete case rather than isolated screens or feature labels.
- Capture the review and the report as distinct records, with their original wording available for assessment.
- Record the concern, evidence examined and reason for the investigation outcome.
- Connect any platform alert, reporting action and follow-up decision to the relevant case.
- Demonstrate an inconclusive investigation without turning uncertainty into a confirmed finding.
- Correct a record while retaining the reason for the change and the responsible decision-maker.
Begin software selection with the same fictional case for every candidate. Include an exception that needs human judgement. Ask the demonstrator to identify each manual step and show how staff return to the case afterwards. Record whether the demonstrated route meets your acceptance criteria, rather than awarding credit for a feature name.
Keep vendor due diligence focused on the exact functions being assessed. Request written confirmation of what the proposed service includes, then compare it with the demonstration record. Separate a supplier's description from an observed result, and record any unresolved question before approving the purchase or expanding the workflow.
Set acceptance criteria before purchase
Define key metrics around the work you intend to test: evidence retained, decisions explained and actions connected to the correct case. Specify what counts as a pass before the demonstration. Keep the same definitions across candidates so that an attractive interface does not substitute for completed case handling.
Illustrative example: "Status: awaiting evidence. Reason: the concern has not yet been verified. Action: refer for investigation. Publication decision: pending approval." Use wording like this to test whether the proposed workflow can preserve uncertainty without presenting an allegation as an established finding or concealing the next decision required.
Make acceptance conditional on the demonstrated route, including correction and unresolved cases. Keep a manual fallback for any task the proposed software does not complete satisfactorily. Repeat the relevant test whenever a proposed change affects how staff capture evidence, investigate a concern, approve an action or publish review information.
