Service

Reviews platform development

For review platform operators and brands collecting reviews across many businesses who need the claim process, verification signals, moderation policy, appeals, business replies, invitation sending, rating rules and widgets designed around their own policy rather than a comments plugin.

The problem

What goes wrong today

Where it usually starts

A review site that starts on a general-purpose platform ends up with a comments thread per business.

  • Anyone can post, so a business gets three glowing reviews in an hour from accounts created that morning and a competitor posts a one-star review from the car park.
  • The operator deletes what looks wrong, with no written reason and no record, and the business that was reviewed finds out by email weeks later.
  • There is no claim process, so a business cannot reply, and when it does reply the operator pastes the reply in by hand.

Where it gets harder

The star rating is whatever the plugin averages, including reviews that were removed and reviews from the same person five times.

  • Businesses that pay for a listing upgrade ask, reasonably, whether paying changes anything, and the operator has no published answer.
  • Invitations to review are sent from the business's own email with a link to the page, so a review cannot be tied to a purchase or a visit.
  • Flags from readers go to an inbox.
  • Nobody can say how many reviews came from invitations, how many were removed and why, how many appeals were upheld, or whether a business's rating has moved because of its own replies or because of a burst of reviews from one network.

Scope of the service

What the build covers

A custom reviews platform build normally covers:

  • Business profiles That can be claimed by a code sent through a channel on the profile, such as the business domain, phone number or postal address, with the claim recorded
  • Review submission that records the route a review arrived by Whether an invitation link sent by the business through the platform, a purchase or booking reference the business supplied, a confirmed email, or an open submission, and shows that route on the review as a signal rather than a verdict
  • A moderation queue where every removal Hold or edit carries a reason from a published policy and is recorded, with an appeal path for the reviewer and the business
  • A right of reply for claimed businesses Shown beneath the review
  • Reader flags that land in the queue with the flag reason
  • Signals that help a moderator Such as many reviews from one network address, accounts created the same day, or a burst of reviews on one profile, shown to the moderator and never acting automatically
  • Invitation sending For claimed businesses with upload of a customer list and a record of who was invited and when
  • An aggregate rating calculated by a rule published on the site From approved reviews only, with the count and recency shown
  • Widgets and feeds a business can embed That show the same figure as the site
  • Data export for businesses and the operator

How discovery works

Discovery follows one review from invitation to appeal with you: which businesses are listed and how claims work, which verification routes you support and how each is labelled, what the moderation policy says and who applies it, how appeals are handled, what a business may do once claimed, whether subscriptions are sold and what they include, how the rating is calculated and where that is published, and what widgets and exports must show. Each answer becomes a named stage in the scope document: list, claim, invite, submit, signal, moderate, publish, reply, flag, appeal, aggregate.

Deliberately out of scope

  • Any claim that the platform has verified a review as genuine, automated removal of reviews on signals alone, and taking payments between readers and businesses. Business subscriptions, where sold, buy tools such as invitations, widgets and exports, and the scope document states that they never touch ratings or review order
  • The published policy on the site says the same

When the scope grows

Scoping scenario

An operator listing businesses across a sector with three verification routes, a moderation team of four applying a written policy with appeals, subscriptions for invitation sending and widgets, and a public page explaining the rating rule. That is a different build from a brand collecting reviews about itself, and the scope document says which is being built.

Deliverables

What you receive

  • Discovery notes from following one review from invitation to appeal
  • A written scope document naming each stage from listing to aggregation, with the policy, rating rule and disclosure wording written out and what is out of scope
  • Design of the business profile, the review form per route, the moderation queue with signals, the appeal flow, the business dashboard and the widget, on mobile for reviewers and desktop for moderators
  • The build, deployed to your hosting or ours
  • Migration of existing reviews with their original dates and routes recorded as "migrated", where relevant
  • Training for moderators and the business support team, with a short written guide for policy reasons and appeals
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts, your business list, existing reviews, the moderation policy as written today and any subscription terms you sell.

    Project stage: Onboarding
  2. Planning

    Discovery with the operator, a senior moderator and business support; the scope document, the policy reasons, the rating rule and the milestone plan are agreed.

    Project stage: Planning
  3. Design

    Clickable designs of a profile, the review form, the moderation queue with signals and the business dashboard, reviewed with two moderators and two claimed businesses.

    Project stage: Design
  4. Development

    Built in stages: profiles and claims first, then submission routes and signals, then moderation, replies and appeals, then invitations, ratings, widgets and exports.

    Project stage: Development
  5. Client review

    Your moderators work a week of real submissions through the queue, run appeals, and claimed businesses send test invitations and embed the widget.

    Project stage: Client review
  6. Revisions

    Policy reasons, signal thresholds, route labels and the rating rule wording are adjusted from the review and re-checked against the scope.

    Project stage: Revisions
  7. Ready for launch

    Reviews migrated, old URLs redirected, invitation and claim emails tested to addresses you control, widgets tested on a business site you control, checklist signed off.

    Project stage: Ready for launch
  8. Delivered

    The platform runs on the new build; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Email and SMS providers for invitations, claim codes and moderation notices
  • Business order, booking or point-of-sale systems supplying purchase references for invitations
  • Card payment providers for business subscriptions
  • Accounting software for subscription invoices
  • Company register look-ups to prefill business details, recorded as returned
  • Structured data and feed formats for widgets on business websites
  • Analytics for invitation, submission and appeal rates

How we would approach it

Worked example

Concept demo

A sector review platform with a four-person moderation team

The situation

An operator listing businesses across one sector had a written moderation policy nobody could apply consistently and a rating that included removed reviews.

Why it is a custom build

This needs a custom build because the policy reasons, the appeal process and the published rating rule are the operator's own, and because they must be enforced by the queue rather than left to habit.

The scope we would propose

  • Claims by a code to the business domain or phone
  • Three submission routes, invitation link, purchase reference and confirmed email, each labelled on the review as the route it arrived by
  • A moderation queue in which every action requires a reason drawn from the policy and is recorded against the moderator
  • Signals such as same-network bursts shown as a panel beside the review, never acting by themselves
  • An appeal path for reviewers and businesses with a second moderator deciding
  • A right of reply for claimed businesses
  • An aggregate rating from approved reviews only, with the rule, the count and the recency weighting published on a page linked from every profile
  • A subscription that buys invitation sending, a widget and exports, with a line on the subscription page and in the policy stating that it never affects ratings or order

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of businesses listed and the claim channels supported
  • Submission routes and how each is labelled
  • Moderation policy depth, team size and the appeal process
  • Signals shown to moderators and the data they need
  • Invitation sending and the order or booking systems that supply references
  • Business subscriptions, widgets, exports and the payment provider
  • Rating rule complexity and the public explanation required
  • Volume of existing reviews to migrate
  • Hosting choice: your own hosting or ours

FAQ

Frequently asked questions

Would the package do, or do we need a custom build?

An operator with claims, the standard submission routes, a moderation queue with policy reasons and a published rating rule is usually covered by the reviews platform package through configuration. A custom build is the honest answer when references must come from several business systems, when the appeal process has several levels, or when the platform must run inside a brand or marketplace. Discovery is where we tell you which.

Does the platform verify that reviews are genuine?

No platform can. What it does is record and show the route each review arrived by: an invitation link the business sent through the platform, a purchase or booking reference the business supplied, a confirmed email, or an open submission. Those are signals a reader can weigh; the platform never calls a review "verified" in a way that implies more than that.

What happens when a review is removed?

The moderator selects a reason from the published policy, the action and the reason are recorded, the reviewer is told and can appeal, and a second moderator decides the appeal. The business can see that a review was removed under the policy but not who flagged it. Removed reviews leave the rating calculation.

Do paid subscriptions change a rating?

No, and the site says so on the subscription page and in the published policy. A subscription buys tools: invitation sending, a widget, exports, response templates. Ratings come from approved reviews by the published rule, and review order is set by the same rule for every business.

Who owns the platform afterwards?

You do. Source code and your data, including profiles, claims, reviews with their routes, moderation and appeal records, invitations and subscriptions, are handed over at delivery; hosting and maintenance are optional and separately agreed.

Get a project quote for reviews software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote