AIOps RFP Template 2026

Sixty questions across eight categories, a 4-point scoring rubric, and the kind of vendor-neutral framing that makes "contact us" pricing impossible to hide behind.

Why most AIOps RFPs fail

Most AIOps RFPs are written by procurement and answered by marketing. Both sides leave the table with a stack of ticked boxes that don't predict whether the platform will actually reduce MTTR or kill three other tools. The questions are too generic ("Does your platform support machine learning?") so every vendor says yes. The scoring is binary, yes or no, so a 40% solution scores the same as a 95% one.

An RFP that works does the opposite. It asks for behaviour, not features. It asks for proof, not promises. It scores on a four-point scale that forces evaluators to defend the difference between "demonstrated" and "claimed." And it weights categories so a $400k three-year contract isn't decided by which vendor has the prettier dashboard.

This template was built after watching twelve buying processes go sideways, Datadog vs. New Relic, PagerDuty vs. Incident.io, Splunk vs. Grafana Cloud, Nova vs. legacy AIOps incumbents. The pattern repeats. The buyer who treats the RFP as a structured discovery exercise, not a checkbox audit, picks better and renegotiates harder.

The eight categories

Every AIOps RFP should cover these eight, in this order. Anything outside them is usually a feature request masquerading as a requirement.

• Detection & correlation (10 questions). How signals are ingested, normalised, deduped, and stitched into incidents.
• Diagnosis & root cause (8 questions). Whether the platform produces a hypothesis or just a chart.
• Remediation & autonomy (8 questions). What the platform can actually do without a human pressing a button.
• Integrations & data portability (7 questions). What goes in, what comes out, and what gets locked.
• Security, compliance, audit (7 questions). SOC 2, ISO 27001, data residency, action audit logs.
• Pricing & commercial model (8 questions). Per-host, per-event, per-GB, per-user, the overage clauses.
• Implementation & support (6 questions). Day-1 to quarter-1, the SLAs that actually bind.
• References & track record (6 questions). Three customers your size, in your sector, who'll take the call.

Sixty questions worth asking

A sample from each category. The full template ships as an editable spreadsheet, these are the ones that separate the field.

Detection & correlation. "Walk me through the last three production incidents your platform correlated automatically, including the false positives. Show me the alert payloads, the correlation logic that fired, and the resolved incident timeline." Vendors who can't produce this on a 30-minute call are running rules engines, not correlation. "What's your false-positive rate on the bottom 25% of customers by alert volume?" The honest answer is somewhere between 18% and 40%.

Diagnosis & root cause. "Show me a single incident where your platform identified a root cause that the on-call engineer would have missed for at least 20 minutes. Provide the timeline, the diagnosis output, and a reference customer who'll confirm." Most "AI root cause" features are just stacked dashboards. The real ones write a paragraph.

Remediation & autonomy. "Of incidents resolved on your platform last quarter, what percentage were resolved without a human action? Break it down by severity tier." If the answer to Sev-1 autonomy is anything above 40%, ask for the audit log. Most vendors pad this with low-severity auto-restarts.

Pricing & commercial model. "What is the all-in three-year cost for 800 hosts, 50 engineers, 2TB/day of logs, with 30% YoY growth? Include every line item, overage, premium support, professional services, training." The "contact us" model collapses when you ask for the math.

References & track record. "Provide three references in our sector at our scale, and one customer who churned in the last 18 months." The churn reference is the most valuable conversation in the entire process.

The 4-point scoring rubric

Binary scoring is useless. Use four points and define each one:

• 0, Not supported. Vendor confirms in writing they cannot do this.
• 1, Roadmap. Promised but not shipped. Always score this as 0 for procurement purposes; revisit at renewal.
• 2, Supported with caveats. Works in some configurations, with professional services, or via a partner. Real but limited.
• 3, Demonstrated end-to-end. Vendor showed a working flow on real or realistic data during the evaluation. This is the only score that should count toward "yes."

The rubric forces evaluators to defend the gap between 2 and 3. That's where most of the surprise renewals come from, features that scored "supported" but were actually "supported in their reference architecture, not yours."

How to weight by deal size

For deals under $100k/year, weight pricing and integrations heaviest. The platform is unlikely to be your last platform; optionality matters more than depth.

For deals between $100k and $400k/year, weight detection, diagnosis, and remediation heaviest, that's where the actual ROI sits. Integrations matter but you can usually buy your way out of a missing connector.

For deals above $400k/year, weight references and security highest. At this size you're betting on the vendor's ability to support you through outages and audits, not just the feature list. The single most expensive RFP mistake at this tier is picking on demos and skipping reference calls with churned customers.

RFP traps vendors love

The everything-is-yes response. Vendor answers "yes" to all 60 questions with a single paragraph each. Always demand a 4-point score with evidence. Sales teams trained on RFPs know "yes" with no evidence reads the same as "yes" with proof.

The pricing dodge. "Pricing depends on your specific configuration." This is true and also a stall. Force a written quote with a 90-day validity window before you sign anything else.

The roadmap promise. "Available in Q3." Score these as zero. If it ships, you'll get it; if it doesn't, you didn't pay for vapourware.

The reference architecture. "Our platform handles 10TB/day at customer X." Customer X's traffic shape is nothing like yours. Ask for a reference at your scale, in your sector, with your data volume, not a logo slide.

How to run the process

Three weeks, not three months. Week one: send the RFP to four vendors, hold a one-hour kick-off with each. Week two: receive written responses, run a 90-minute structured demo with each, same script, same data, same observers. Week three: reference calls, pricing finalisation, internal scoring meeting, decision. Drag this past four weeks and you'll lose your champion to another priority.

One scoring meeting, three voting members minimum, recorded scores per question per evaluator. Disagreements get resolved by re-watching the demo recording, not by re-arguing. The decision falls out of the spreadsheet, not the room. That's how you avoid the "we picked the one we liked" outcome that gets re-litigated at renewal.