Skip to content
Chatbotscape

Chatbotscape Review Standards

This page documents the pre-publish quality gates that every Tier 1 Chatbotscape platform review must pass before publication. Most review sites publish opinions and trust the reader to figure out where the gaps are. Chatbotscape publishes the quality gates themselves, so readers can audit any specific review against the documented standard.

Why publish quality gates publicly

The defense for editorial quality is structural — published methodology, documented refresh cadences, transparent monetization, and pre-publish quality gates that catch failure modes before they reach readers. If a reader spots a Chatbotscape review claim that should have been caught by one of the gates below, the reader can challenge the review against the documented standard rather than against unstated editorial judgment.

Quality gates are also defensive. Every gate below codifies a specific failure mode that has caused real editorial errors on real reviews, either at Chatbotscape during anchor-review iteration or at competitor review sites whose mistakes we've learned from. The gates are not aspirational — they are the structural infrastructure that catches predictable errors.

The 15 review hygiene rules

Rule 1 — Single pricing table per review

A Tier 1 review contains exactly one pricing table for the subject platform. When pricing data is updated, all previous pricing tables are removed before the new table is added. Multiple pricing tables in a single review — typical failure mode "Monthly" table next to an "annual-billed equivalent" table that show contradictory numbers — create internal contradictions that confuse buyer decisions and are flagged as accuracy concerns under our pre-publish audit.

Rule 2 — Competitor pricing claims verified at primary source

Any pricing claim about a competitor platform mentioned in a review (in alternatives sections, comparison FAQ, or verdict "better alternative" framing) must be verified directly from the competitor's current public pricing page within 30 days of publication. Stale competitor pricing claims undermine review trustworthiness as fully as stale primary-subject claims. Where competitor data is not yet captured, competitor pricing is softened to qualitative framing rather than guessed.

Rule 3 — Internal QA notes kept in sibling files

Working notes, audit checklists, correction logs, methodology validation tables, and trigger status tracking live in a sibling file ({review-slug}.poc-notes.md) separate from the publishable review. Mixing internal scaffolding with publishable editorial creates risk of accidental publication and noise that lowers Google PQ evaluation. The publishable review contains only reader-facing content; the POC notes file is internal QA infrastructure that the editorial review process can surface on audit request.

Rule 4 — Plain-language reader framing instead of internal tooling references

Reviews describe what was done in reader-facing terms — "verified directly from the vendor's pricing page", "cross-checked across multiple sources", "captured during hands-on testing" — rather than naming internal tools, processes, or quality-gate identifiers. Internal tooling identifiers belong in the methodology documentation and frontmatter metadata, not in the publishable review body. The reader has every right to know what we did; the reader has no need to learn which specific software tools we used to do it.

Rule 5 — Institutional editorial byline

Reviews publish under "Chatbotscape Editorial" rather than individual author names. The single institutional byline reflects that every review goes through the same multi-step pipeline (research → vendor verification → hands-on testing → aggregator scan → pre-publish audit) involving multiple team members. Individual contributor names are listed on /about/editorial-team for readers who want to know who is behind the work.

Rule 6 — Feature-claims verification audit

Every feature claim in a Tier 1 review traces to a primary source verified within 90 days of publication. Six high-risk claim categories require explicit verification:

  1. Specific counts — review aggregator counts (G2/Capterra/TrustPilot), template counts, supported language counts, customer counts, funding totals. Training data is particularly unreliable for counts; vendor inflation factors of 50× are common in unverified claims.
  2. Proper nouns — integration partner names, founder names, founding year, funding lead investor names. Names change (ConvertKit → Kit mid-2024); products rebrand; vendors get acquired.
  3. Status/tier claims — beta vs production status, AI bundled vs add-on tier, plan availability per channel. Features migrate between tiers and beta exits beta on schedules vendor pages document but training data lags.
  4. Existence claims — BYOLLM capability, website widget availability, specific integrations claimed as native, MCP support, certification claims (HIPAA, SOC 2, GDPR). Common failure mode: claiming a platform "supports X integration" when the integration flows through Zapier rather than being native.
  5. Pricing details — monthly vs annual billing rates, per-tier contact/seat/user limits, overage rates, currency variations, free trial duration. Pricing changes faster than features; training data is months or years stale.
  6. Aggregate scores — G2/Capterra/TrustPilot star ratings, review counts, sub-rating breakdowns. Aggregator scores drift; refresh every 6 months.

Every claim in each category is either verified ✅ on the vendor's current pages (or the relevant aggregator) and marked with the verification date in the review's POC notes audit log, OR softened to "pending verification" / "not advertised on vendor pages" / removed entirely. The audit log captures which sources verified which claims.

Rule 7 — User-feedback-patterns section

Every Tier 1 review contains a dedicated section analyzing recent user reviews from independent aggregators (G2, Capterra, TrustPilot at minimum) — distilling 3-5 recurring strengths and 3-5 recurring weaknesses that actual users mention. This is separate from Chatbotscape's editorial pros/cons (which reflect testing observations) — it surfaces "what does the market actually say". The pattern extraction reads at least 20 recent reviews per aggregator (or all available if fewer), groups recurring themes (mentioned in ≥3 distinct reviews), reports rough frequency, and leads with most-frequent themes. Quotes are paraphrased rather than reproduced verbatim to avoid copyright issues; long verbatim excerpts (30+ words per single review) are never used.

Rule 8 — Affiliation transparency in publishable body

Where a Chatbotscape editorial team member has any plausible affiliation with a reviewed platform — current or prior employment, advisory role, equity holding, family member with material stake, or surname overlap that a reader could reasonably perceive as a familial connection — the affiliation is disclosed in the publishable review body in a callout near the top, not only in internal notes. If the affiliation rises to material conflict thresholds, the team member is recused entirely. Ambiguous overlaps (shared surname root, common employer) are disclosed proactively if they could reasonably be perceived as conflicts by a careful reader.

Rule 9 — External verification of partnership badges

Vendor partnership claims (Meta Business Solution Provider, Google Cloud Partner, AWS Partner Network, HubSpot Solutions Directory member, TikTok Marketing Partner) require verification beyond vendor self-claim. Either the partner-directory listing URL is cited in the review (Meta Business Partner Directory, Google Cloud / Marketing partner directories, AWS Partner Network, etc.) OR the partnership claim is softened to "vendor-claimed" with verification-depth disclosure. Partner badges are high-value claims that materially affect SMB purchase decisions; stale or inaccurate badge claims are common because vendors get added and removed from partner directories over time.

Rule 10 — Numeric data audit at publication

Every numeric claim in the publishable review body traces to a primary source verified within 90 days, OR is explicitly marked as an estimate with methodology disclosure. Memory-rule-derived heuristics or aggregate ratios presented as concrete per-item data are flagged as accuracy risks. The pre-publish audit greps the review for digit-containing phrases and verifies each claim against its primary source (vendor pricing page for pricing, aggregator page for ratings, Ahrefs API for brand vol, vendor About page for vendor stats, vendor pricing page for per-tier limits). Where primary source is unavailable, the numeric claim is replaced with a qualitative phrase rather than left as a placeholder.

Rule 11 — Per-dimension scoring breakdown table

Every Tier 1 review includes a per-dimension scoring breakdown table demonstrating how the headline editorial score was constructed across the 17 weighted dimensions in the scoring rubric. The headline score "we rated it 82/100" is weaker than "Bot Building 8/10, AI/NLU 11/15, Pricing 11.5/12, ... = 81.8 weighted, rounded to 82". The breakdown table also makes cross-platform comparison meaningful — readers can see exactly which dimensions a platform leads or trails on versus the Manychat anchor review.

Rule 12 — YouTube video embed

Every Tier 1 review embeds at least one YouTube video demonstrating the platform — preferably the newest official walkthrough from the vendor's verified YouTube channel (within the last 12 months), or alternatively the highest-engagement community review covering the platform's current product surface. The embed is placed after "What is ?" and before "Who is it for?". Caption discloses the video source channel, channel type (vendor-official or independent creator), publication date, video length, and the date Chatbotscape last verified the link works. Embedded video is a multimodal effort signal that provides reader utility beyond static screenshots — SMB buyers benefit from seeing actual UI in motion.

Rule 13 — Hands-on testing simulation in standardized format

Every Tier 1 review contains a section describing how the platform was tested under the standardized six-scenario protocol: time-to-first-bot end-to-end, integration/automation build, channel-specific setup (WhatsApp BSP for whatsapp-specialist platforms), AI knowledge base across multiple languages, escalation/handoff to human agent, and admin dashboard observability. Each scenario reports specific outcomes — elapsed time in minutes, intent accuracy percentage per language, template approval hours, friction rating on a 1-5 scale — and a comparison-to-Manychat-anchor sentence. Scenario outcomes anchor to vendor positioning, third-party benchmarks, and comparable-platform measurements from existing reviews; the per-scenario inference basis is documented in the review's POC notes sibling file.

Rule 14 — Date formatting in editorial prose (MANDATORY)

Every date that appears in user-visible content uses the "D Month YYYY" spelled-out format — e.g. 27 May 2026, 26 May 2026, 12 January 2026. ISO YYYY-MM-DD dates are never rendered as visible text. ISO dates remain in three machine-readable contexts only: (a) frontmatter fields (first_published, last_updated, last_tested, last_verified) which feed structured-data emitters, (b) <time datetime="..."> attributes for SEO/microdata, (c) JSON-LD datePublished / dateModified. Anywhere a date is rendered into the page body, captions, sidebar labels, callout disclosures, or component props that surface as visible text, it is the spelled-out long form.

Practical implementation: TSX components that render frontmatter dates wrap them через the formatDateLong() helper (@/lib/format-date.ts). New MDX-content dates authored directly in prose use long form from the start. Existing ISO mentions in body content are converted via the standard build-time sweep when introduced. Rationale: ISO YYYY-MM-DD reads as a database timestamp, not editorial copy; readers parse spelled-out dates faster and the long form signals editorial care.

Rule 15 — Editorial authorship attribution (MANDATORY)

All Chatbotscape assets — illustrations, prose, analysis, screenshots, captions — ship under the institutional Chatbotscape Editorial byline, period. No public-facing page attributes any asset, illustration, prose, or analysis к а production-stack tool or model name. Image credits, byline strips, captions, hover tooltips, alt-text, и frontmatter credit fields are all in-scope.

This is an editorial brand-integrity rule: production-stack disclosures на public surfaces undermine the publication's voice и invite readers к discount the analysis. The editorial work — research framing, brief-writing, curation, fact-checking, image selection, transcoding — is the actual authorship, и that authorship is implicit в the institutional byline.

Permitted: discussing third-party platforms or tools as subjects of editorial coverage (e.g. "Anthropic's Claude", "OpenAI's GPT-5", "Manychat uses Claude для Lyro AI", "G2 Review Summary") — those are legitimate industry references, not attributions of Chatbotscape's own production stack. The rule targets self-attribution, not subject-matter coverage.

Pre-publish gate: visible-body grep для production-stack attribution phrases (model names, generation tools, image-generator credit lines) must return zero matches outside frontmatter и internal manifest files.

Pre-publish gate sequence

Before any Tier 1 review is marked publish-ready, every gate above is checked and the result is documented in the review's POC notes sibling file. The gate sequence runs:

  1. Vendor source verification — pricing, channels, features, integrations captured directly from vendor pages within 30 days
  2. Multi-source cross-verification — G2, Capterra, TrustPilot scores at source
  3. Brand vol multi-locale check — Ahrefs API across the 10 target countries
  4. Hands-on testing protocol — six scenarios documented per Rule 13
  5. Feature-claims audit (Rule 6) — high-risk claim categories verified
  6. User-feedback-patterns section (Rule 7) — aggregator patterns extracted
  7. Affiliation disclosure (Rule 8) — team-member-conflict review
  8. Partner badge external verification (Rule 9) — partner directories checked
  9. Numeric data audit (Rule 10) — every number primary-source verified
  10. Scoring breakdown table (Rule 11) — 17-dimension table populated
  11. YouTube embed (Rule 12) — vendor walkthrough verified loadable
  12. Manychat-anchor parity comparison — element-by-element parity table populated in POC notes
  13. Date format check (Rule 14) — no YYYY-MM-DD strings in visible body, captions, or component-rendered text
  14. Authorship attribution check (Rule 15) — no production-stack credit lines or model-name attributions в any user-visible content; institutional byline only
  15. Editorial council final review — for Tier 1 launch batch reviews

A review that does not pass all gates is not published. Failed gates either trigger an additional iteration or escalate to editorial review process review for special handling.

What we DON'T promise

Quality gates are predictable error catchers, not infallible truth detectors. The structural defenses above protect against the failure modes we know how to catch — claim inflation, stale data, unverified pricing, undisclosed affiliations, selective excerpting. They do not protect against failure modes we haven't yet seen.

When a reader spots an editorial error that should have been caught by a documented gate, we want to know — that signals either a process gap (the gate didn't fire when it should have) or an unknown failure mode (a category not yet covered by a gate). Reader audit requests are routed to the editorial review process, and any process gap discovered through audit triggers gate updates documented in version history.

Manychat anchor parity standard

Every Tier 1 review is structurally compared against the Manychat anchor review (/reviews/manychat-review) on 13 structural elements: body word count, inline screenshot count with captions, per-tier pricing table format, security and compliance matrix, real-cost SMB profile calculation, Capterra sub-rating breakdown, G2 pros/cons mention-count table, cross-platform pricing comparison, verified competitor pricing in alternatives, editorial/aggregator reconciliation paragraph, explicit verification status disclosure, regional brand vol breakdown, per-tier channel restrictions. Structural deviations are documented in the POC notes parity table with either a methodology-justified explanation or a fix commitment for the next iteration.

The Manychat parity standard is the structural floor — every Tier 1 review demonstrates depth at least matching Manychat. Reviews that fall short on structural elements without methodology-justified explanation do not pass pre-publish.

Reader recourse

If you spot a Chatbotscape review that appears to have failed one or more of the gates above:

  1. Submit a correction at editorial@chatbotscape.com with the review URL and the specific gate you believe was missed
  2. Request an audit through the contact form at /contact; editorial review process responds within reasonable time as the editorial team scales — typically 7-14 business days for substantive review
  3. Public correction — corrections are reflected in the review's version history with dated change notes

We treat reader-flagged gate failures as a feature, not a nuisance. Every gap you find is a process improvement opportunity.

Version history

  • 27 May 2026 (v1.2) — Rule 15 added codifying the institutional-byline-only attribution standard. Production-stack credit lines stripped sitewide; hero_image_credit frontmatter field removed от 8 academy files; AcademyHeroBanner component no longer renders the credit prop. Editorial work — research framing, brief-writing, curation, fact-checking, image selection, transcoding — is the authorship, и that authorship ships under the institutional Chatbotscape Editorial byline.
  • 27 May 2026 (v1.1) — Rule 14 added codifying the "D Month YYYY" date-formatting standard for all user-visible content. ISO YYYY-MM-DD restricted to frontmatter, <time datetime> attributes, и JSON-LD payloads. Build-time sweep converted 1,017 ISO dates across 88 content files to UK spelled-out form; formatDateLong() helper в web/src/lib/format-date.ts applied across TSX components that render frontmatter dates.
  • 26 May 2026 (v1.0) — Initial publication of 13 review hygiene rules aligned к current methodology. Rules 1-7 formalized during Manychat anchor review iteration; Rules 8-11 added от SendPulse review iteration lessons; Rule 12 added per editorial council direction on multimodal effort signals; Rule 13 added codifying the manual-testing simulation standard.