The standard customer service RFP rewards the wrong things. Here are 40 questions, six dimensions, and eight instant-disqualifiers that fix that.

What to score, and how much each dimension is worth, before you talk to a vendor.

Weights are published below with their rationale so the scoring is auditable. Adjust for your context (regulated industries should weight security higher; bootstrapped teams running a 30-day pilot should weight implementation higher). What matters is that the weights are set before you see any vendor response, not after.

Why accuracy is the heaviest dimension. Security is mostly binary in practice. A vendor either has SOC 2 Type II, a sub-processor list, a DPA, and tenant isolation, or they fail the gate. Accuracy is where serious vendors actually differ. The published pre-launch threshold, the QA AI architecture, the deflection-vs-resolution distinction, the typed tool layer, the audit trail granularity, these are where production safety lives, and they are precisely the dimensions a slick demo does not test. Weighting accuracy at 25% forces the buyer to spend most of the diligence budget where the actual variance is.

Why workflow fit is next. Even an accurate AI is operationally useless if it cannot reach into the systems where the work actually happens (Shopify, Recharge, Loop, Klaviyo, ShipStation, your custom OMS) or if its escalation handoff drops context. The Persona 3 mid-market buyer in our 2026 evaluation cohort cited handoff fidelity and multi-system integration depth more often than any other operational concern.

Why pricing is weighted modestly. Not because price is unimportant, but because pricing dispersion across serious AI customer service vendors is narrower than buyers expect. The dispersion that matters most is on total cost of ownership (overages, integration fees, professional services, sub-processor passthrough), not headline list price. The five pricing questions below are designed to flush out the hidden costs rather than to compete on $/conversation.

Eight instant disqualifiers, regardless of category scores.

A vendor can score 95 across all six dimensions and still be wrong for production if any of the patterns below appears. Treat these as gates, not as inputs to the weighted total.

How to verify the answers, not just collect them. What good actually looks like.

RFP responses are written by sales engineers, not by production teams. The scoring above only works if you verify the answers against artifacts. Three verification moves separate the diligent buyer from the buyer who gets surprised in month four.

One: ask for the product UI, not the deck. Every claim about the QA layer, the audit trail, the escalation triggers, the tool definitions, every one of these should be answerable by a live demo of the product UI, not by a slide. If the vendor cannot show the artifact in the product, the feature is on a roadmap and you should score it as a 1, not a 2 or 3.

Two: run the pre-launch eval as a contractual condition. The vendor's accuracy score on your historical tickets is the single most predictive metric in the entire evaluation. Make it a contractual condition (not a courtesy) that the AI must clear the published threshold on your tickets before the contract effective date. Vendors who balk at this are telling you the threshold is aspirational.

Three: structure reference calls around failure, not success. Standard reference questions ("how was your onboarding?") produce standard reference answers. The questions that produce signal are: "Tell me about a time the AI got something wrong in production. How did the vendor respond?" and "What surprised you in month three or month six that the sales process did not prepare you for?" A vendor's references will answer these honestly if they are real customers. A vendor's references will hedge or redirect if they were curated.

What this looks like in practice: across roughly 1,000 Richpanel customer onboardings, the production safety pattern that correlates most strongly with successful long-term deployment is not the highest demo accuracy score; it is the willingness of the buyer to insist on a pre-launch eval gate before live traffic. Buyers who skip that step often get exactly what the vendor measured: not what their own data actually demonstrates.

For an architectural deep-dive on the accuracy dimension specifically, see the companion piece on the four-layer hallucination defense. That article goes further into the QA AI architecture, the typed tool boundary, and what each layer's failure modes look like in production.

What this rubric does not catch, and what to do about it.

Even a rigorous scoring process has known blind spots. Naming them is part of using the rubric well.

• Organizational culture of the vendor. No 40-question RFP detects whether the vendor's engineering team responds to a Sev-1 incident at 2am or sends a templated apology and a Tuesday update. Reference calls structured around failure (the third verification move above) are the only reliable proxy.
• The quality of the deployment engineering team that touches your account. Vendors can have excellent architecture and a weak deployment bench. Insist on naming the implementation engineer assigned to your account during contract negotiation and treat unwillingness to do so as a soft disqualifier.
• Model-provider risk over a multi-year horizon. The frontier model landscape moves quarterly. A vendor locked to a single provider whose pricing or capability profile shifts is exposed. Multi-model support (Q17) is the partial hedge; long-term, the buyer's contract should include a model-change notification clause and reset rights if the underlying capability materially changes.
• Edge cases that have not yet occurred. The 15% to 30% pre-launch hallucination rate on ungrounded LLMs cited in the companion architecture piece is a measurement; it is not a prediction about which specific failures you will see. Mitigation lives in the four-layer architecture, not in the RFP.
• Cultural fit with your CX team. The AI's tone, the rollout cadence, the change-management discipline, all of these matter and all of them resist scoring. The collaborative-mode-then-autonomous-mode rollout pattern documented across the April to May 2026 mid-market cohort is the operational answer to most of this; the RFP cannot substitute for actually running the pilot.

The honest framing of this rubric is not "score every vendor on these 40 questions and the winner is the right vendor." It is "use these 40 questions plus eight instant disqualifiers to narrow your shortlist from five vendors to two, then run a real pilot to choose between the final two." The pilot is the actual selection mechanism. The RFP is the pre-filter that keeps the pilot from being a waste.

Run this on your own shortlist.

The complete rubric, with all four anchored scoring bands for every one of the 40 questions, a pre-populated Google Sheets scorer, and the eight instant disqualifiers wired as conditional formatting, is available on request. Email amit@richpanel.com with the subject line "RFP rubric" and the cohort of vendors you are evaluating, and we will send the sheet within one business day. No demo gate, no marketing nurture sequence. The rubric is more useful in the field than on a website.

If you would also like Richpanel scored honestly against the rubric (including the dimensions where we score 1 or 2), include that in your email. We score ourselves the same way we ask buyers to score every other vendor, by sending the spreadsheet back with our cells filled in and our reasoning per cell.