The Voicify "Competitor A or Competitor B" battlecard is an internal artifact. It names competitors, exposes slot mechanics, pre-loads objection rebuttals, and is designed to be read by a rep in the four minutes before a discovery call. None of that translates to the buyer side of the table. What translates is the comparison matrix — the one-page leave-behind the rep sends after the call to support the DSO's internal evaluation. The matrix carries the same evidence rows as the battlecard, but the slot labels are stripped, the competitor names are normalized in the column headers, and the rebuttal language is removed. This is the artifact the dental AI sales team builds once and renders twice: once internally with slot tags, once externally without.
TL;DR
Ten rows. Three columns. Zero slot labels. The Voicify A-or-B comparison matrix is the buyer-facing rendering of the internal battlecard. Ten neutral evaluation rows cover integration depth, deployment time, training overhead, per-location pricing, contract structure, support model, data residency, dental specificity, references, and roadmap visibility. Three product columns name Voicify and up to two competitors. The slot tag from the battlecard is stripped at render time; objection rebuttal language stays internal. The matrix is the leave-behind after a discovery call, not the document the rep reads during the call. Build it from the battlecard, audit it with the same QA checklist, refresh it on the same quarterly cadence.
What the Matrix Is, and Is Not
The comparison matrix is a one-page document, ideally a single PDF or single screen of a microsite, that lets a DSO evaluator compare Voicify against the one or two dental AI vendors they are also looking at. It is not a battlecard, not a sales deck, not a product brochure. The closest analog is the comparison table at the bottom of a B2B SaaS pricing page — but where the SaaS table is a marketing artifact built once and left static, the matrix is rendered per-deal from the same source of truth as the rep's internal battlecard. The slot tag from the battlecard governs which evidence rows surface; the slot tag itself never appears on the page the buyer sees.
The distinction matters because the buyer can tell the difference between a generic comparison page and a deal-specific matrix. A DSO evaluator comparing Voicify against a dental-pure incumbent will trust a matrix that names the dental-pure competitor by its actual product name, lists the integration depth their PMS actually has, and references DSOs in their size band. They will not trust a static page that obviously was not built for their evaluation. The cost of the per-deal render is low because the source data lives in the battlecard system; the neutralization filter is what runs at render time.
The Ten Rows
Ten rows is the working maximum. Six is the floor. Below six rows the matrix reads as a marketing one-pager; above ten the buyer stops reading. The row headers below are the neutral framings — never name a competitor in the row label, because the row label is where credibility is built or lost.
| Row | What the row asks | Why it earns trust |
|---|---|---|
| 1. Integration depth | Which PMS integrations are certified, which are partner-supported, which require professional services | DSO evaluators rank this row first because it determines deployment cost in their existing tech stack |
| 2. Deployment time | Days from contract to first live call answered, by deployment model | Concrete time-to-value comparison; resist the urge to quote a single number — quote a range with assumptions |
| 3. Training overhead | Hours of office-manager and front-desk training required to reach steady state | Office-manager objection lives here; the matrix lets the buyer see training cost without the rep having to raise it |
| 4. Per-location pricing | Monthly per-location list and the discount curve at 10, 25, 50, and 100 locations | DSO buyers price on per-location math, not per-call; show the curve, not a single point |
| 5. Contract structure | Minimum term, ramp-down language, location-add and location-remove clauses | The DSO's procurement team reads this row most carefully; ramp-down language is often the decisive comparison |
| 6. Support model | Hours of coverage, response-time SLAs, named CSM threshold, dental-specific support staffing | Dental-specific support is the differentiator most often left off generic comparisons |
| 7. Data residency | Where call recordings and PHI are stored, BAA terms, retention defaults, audit-log access | HIPAA-adjacent buyers need this row even when they cannot articulate why |
| 8. Dental specificity | Number of dental DSOs in production, dental-specific intent models, dental scheduling logic depth | The row that separates Voicify from horizontal AI voice vendors and from dental-pure competitors |
| 9. References | Reference DSOs by size band (under 10, 10-50, 50-200, 200+), redacted by name unless permission granted | Size-banded references read as honest; named references without permission read as careless |
| 10. Roadmap visibility | What ships in the next two quarters, public commitment level, customer-influence channel | DSO evaluators ask about roadmap in 80 percent of deals; not having a row for it makes the matrix feel incomplete |
The Three Columns
The matrix has three product columns — Voicify, the dental-pure competitor surfaced in the discovery brief, and a third reference column if the buyer is evaluating a third vendor. The column labels are the actual product names; the slot tag never appears. If the buyer is only evaluating two vendors, the matrix is two columns plus a sticky-note row at the top noting which vendor is currently incumbent (if any). If the buyer is evaluating four, drop the lowest-fit option from the matrix and offer to render a four-column version on request — the page-level readability falls off a cliff at four product columns on a single sheet.
Column order is alphabetical by product name, not by slot preference. A matrix that lists Voicify first when Voicify is alphabetically second reads as biased, and the buyer notices. The slot tag in the battlecard is what tells the rep how to position Voicify in the conversation; the column order in the matrix follows a deterministic rule the buyer can verify.
What Never Appears on the Matrix
Three categories of content live in the battlecard and stay there. First, slot mechanics — no A-or-B framing, no slot decision tree signals, no incumbent-versus-challenger language. Second, objection rebuttal language — the matrix is an evidence artifact, not a refutation artifact, and rebuttal phrasing belongs in the rep's hand during the call, not in the buyer's hand after it. Third, named customer references without explicit written permission — size-banded references are acceptable, identified ones are not. The neutralization filter at render time enforces all three. If a row in the battlecard fails any of the three tests, it does not surface on the buyer-facing version. For the full neutralization rule set, see our naming rules.
Render Once, Audit Twice
The matrix is rendered from the same source of truth as the battlecard. The implementation pattern is a single row-level data structure with two render modes: internal (slot-tagged, competitor-named, rebuttal-loaded) and external (slot-stripped, alphabetical, evidence-only). The QA checklist that audits the battlecard runs against both modes on the same quarterly cadence — the internal audit confirms the slot mechanics are correct; the external audit confirms the neutralization filter is working. For the audit shape, the QA checklist covers the row-level integrity tests that apply to both modes.
The win/loss debrief reads the matrix and the battlecard side by side. When a deal closes won, the post-call review confirms that the matrix the buyer received matches the slot the battlecard was rendered to — a slot-A deal whose matrix surfaced slot-B evidence rows is a render-time leak that the system needs to catch before the next render. When a deal closes lost, the review checks whether the matrix's roadmap row or pricing row was the cited reason, which feeds the next quarter's evidence refresh on those rows specifically. The matrix is not a one-time artifact. It is the externalized state of a system that lives behind it.