Six red flags in a software RFP response (and what they predict)

There is a particular weight to a software RFP response that does not say very much over fifty pages. The procurement team feels it. The technical evaluators feel it. But on the scorecard, it scores fine - every requirement is "addressed", every checkbox is ticked. The vendor passes the first round.

Eight months later the same procurement team is doing a stop-work review and trying to understand where it all went wrong.

The problem is that scorecards are designed to compare answers, not to read between them. The signal in an RFP response sits in how the vendor answers - the structural choices they make about specificity, ownership, and what they are willing to put in writing. After a decade of writing these from the vendor side and reviewing them as a delivery partner for client procurement teams, six patterns come up consistently as predictors of trouble.

Use these as a layer on top of your scorecard, not a replacement.

Red flag 1: the requirement is restated, not answered

The cleanest tell. A requirement says "the system must support SAML 2.0 SSO with SCIM 2.0 provisioning, scoped per subsidiary." A weak response says: "Our platform supports enterprise-grade single sign-on integration with major identity providers, including configurable provisioning for multi-tenant deployments."

That sentence does not say SAML. It does not say SCIM. It does not say what "configurable" means. It does not address subsidiary scoping. It restates the requirement in marketing language and earns the checkbox.

A strong response says: "Yes - SAML 2.0 IdP-initiated and SP-initiated flows supported, certified against Okta, Azure AD, Ping. SCIM 2.0 push provisioning with per-tenant scoping via the externalGroup attribute. Tenant boundaries enforced at the data layer (not just UI)." Specific, named, falsifiable.

When you see five or six requirements answered in the first style, assume the rest are too. Score it accordingly.

Red flag 2: no named delivery lead

The proposal has a "team" section. There are headshots and titles. Nobody on that page is committed to staying on your account from kickoff through go-live.

Body shops staff projects from a bench. The lead engineer in your kickoff meeting is sometimes a different person from the one in your six-month review. Continuity decays silently. By the time you notice, you are explaining your domain to your fourth project manager.

Ask for one thing in writing: who is the named delivery lead, and what is the contractual commitment to their continuity? A credible answer names a person, states the commitment period (typically 12 months minimum), and describes what happens if they have to be replaced (notice, handover overlap, your right to interview the replacement). If the vendor cannot do this, the team page is decoration.

Red flag 3: case studies that mention industry but not architecture

Strong case studies name what was built, what it integrated with, what scale it ran at, and what changed measurably. Weak case studies say "we delivered a digital transformation for a leading Asian bank" and move on.

The reason this matters is not credentialism. It is that the architecture of past work is the most reliable predictor of the architecture they will propose for you. If their public case studies do not describe the technical shape of past systems, either (a) they cannot describe it because it was off-the-shelf assembly, (b) they cannot describe it because the architecture was bad, or (c) they have no anonymisation framework and so cannot publish anything substantive.

Option (c) is forgivable. Options (a) and (b) are not.

A reasonable counter: ask for an architecture diagram of one past project, redacted as needed. A vendor that has built real systems can produce this in a day. A vendor that has not will spend two weeks producing something that looks like marketing.

Red flag 4: SLA language that excludes its own root causes

Every RFP has an SLA section. Most are 95% or 99% uptime, with service credits if missed. Look at the exclusions.

Common exclusions that quietly cancel the SLA:

• Third-party service outages. If the vendor's system depends on a payment gateway, an IdP, an email service - and the SLA excludes "outages of third-party services" - then 80% of real downtime is unmetered.
• "Force majeure" defined broadly. Includes things like "any failure of underlying cloud infrastructure", which means the SLA does not actually cover cloud outages.
• "Scheduled maintenance" with no cap. No cap on how often, how long, or when. A vendor can declare scheduled maintenance every Friday for six hours and remain "100% in SLA".

A strong response defines SLA in terms of measurable user experience (e.g. "p95 page-load latency under 800ms during business hours"), names specific exclusions narrowly, and caps scheduled maintenance to a fixed budget per quarter. Service credits in a strong response are non-trivial - if missing the SLA costs the vendor 1% of monthly fees, the SLA is decorative.

Red flag 5: pricing that hides the integration tail

The headline price covers the software. It does not cover what it takes to make the software work inside your environment. Look for what is not included.

Specifically: what does the vendor charge for integrations that show up as "supported" on the website but require a paid services engagement to actually configure? What is the per-environment, per-tenant, or per-user uplift that kicks in at higher volumes? What happens to pricing when you cross from "production tier 1" to "production tier 2" (which usually means: when your usage grows)?

The pattern to watch for: a tidy first-year price that locks you in, and a year-three TCO that is double what you signed for - because every integration billed as "supported" cost six weeks of professional services, and every scaling event triggered a tier change.

Ask for a three-year TCO scenario assuming 2x your initial user volume and three additional integrations (named) past the included set. A vendor that has thought about this can produce a credible answer. One that has not will hedge with "this depends on your specific requirements" - which is true, but does not let you compare proposals.

Red flag 6: refuses to discuss exit

The proposal describes onboarding, training, and ongoing support in detail. Exit is a single sentence: "Standard data export available on request."

Vendor exit cost is asymmetric. The vendor is incentivised to make it expensive; you are incentivised to make it cheap; the contract has to enforce the balance. A vendor that does not want to put exit terms in writing during the proposal phase will not want to put them in writing during the contract phase, and certainly not when you are leaving them.

Ask three specific exit questions:

• What format is the data exported in? Specific schemas, not "industry-standard formats". A CSV dump of customer records is not equivalent to a relational export that preserves foreign keys.
• What is your maximum data export time, and what does it cost? A 6 TB export should not take three months. If it does, that is by design.
• What integrations can be re-pointed during exit? If the vendor's system writes to your CRM via a proprietary connector, who owns that connector during the transition? You want a clean answer.

This is a separate, longer post about vendor lock-in. The RFP stage is when to surface it.

How to actually use this

Pick the next vendor response you read. Score it twice. The first time, on your scorecard. The second time, on these six signals - just three columns: red flag yes/no, evidence, severity (1-3).

You will find that the proposals that scored highest on the original rubric and the proposals that scored highest on the red-flag rubric are not always the same. When they disagree, the red-flag rubric is more often right - because it is reading delivery posture, not marketing fluency.

If you want a second pair of eyes on a specific vendor response, book a 30-minute call.