The questions missing from your RFP
APIM RFP grids run to a hundred lines on features and three on operations. The ten questions that are missing, and what their answers reveal.
APIM RFPs all look alike: a grid of one hundred to three hundred lines, inherited from a consultancy or an earlier project, where every vendor answers "compliant" to 90% of it. The grid is long because it is easy to lengthen: every feature is one line. And it does not discriminate, because the products on the market have all covered the functional essentials for years.
What sets them apart is elsewhere, in questions that fit in ten lines and that are missing from almost every grid.
The ten questions
1. Describe upgrading your product from N-1 to N on a platform in production. Duration, interruption or not, rollback possible or not. It is the operation that will hurt your teams most over ten years, and it is never in the grid.
2. Is your full configuration exportable and applicable through an API, with no console action at all? Not "do you have an administration API": the question is coverage. Every object configurable in the console must be configurable from the pipeline, otherwise the gap will become your unmanageable stock of configuration.
3. What does the operator see during a failure of one of your internal components? The quality of the product's internal diagnostics, error messages included, decides how long your incidents last. Ask for a demonstration on an induced failure, not a dashboard screenshot.
4. What is the behaviour of the gateways when the control plane is unavailable? The right answer fits in one word: nothing. Traffic keeps flowing, the configuration is frozen. Any other answer deserves a close examination.
5. Give the exhaustive list of metrics and logs exportable to our own tooling. Your observability must live in your tools, not in the vendor's console. The format, the delay and the cost of the export are three classic traps, the third above all: some pricing models bill data egress.
6. What does your pricing scale with, and what happens at twice our forecast traffic? Per call, per gateway, per core, per environment: every model has a scenario where the bill explodes. Running the numbers at twice the forecast reveals yours before signature.
7. Which features in your answer are generally available, and which are on the roadmap? With dates and contractual commitment. The border between the product and the roadmap is the most creative area of RFP answers.
8. How many people on our job market can actually operate your product? A brilliant product with no local skills pool ties you to the vendor's professional services for every change. The cost of that tie is in no grid, and it is exactly what we measure when we look, for a client, at who really knows how to run the platform they are buying.
9. Give three customer references at our scale, one of which we will choose to call without you present. A reference call with no vendor in the room is worth more than any demonstration. The questions to ask fit in three lines: version upgrade, worst incident, what they would do differently.
10. What becomes of our configuration if we leave? Export format, documentation of that format, reversibility clause. The answer measures the vendor's confidence in its product: those who keep their customers through the difficulty of leaving know it.
How to read the answers
An open question is only worth asking if you have written down in advance what counts as disqualifying. Otherwise the answer is long, friendly, and scored "compliant" like the rest.
| Question | The answer that eliminates |
|---|---|
| 1. Version upgrade | An announced interruption with no duration, or a rollback "case by case" |
| 2. Configuration through an API | "Everything is possible through the API", with no list of the objects that are not covered |
| 3. Internal failure | A dashboard screenshot instead of an induced failure |
| 4. Control plane unavailable | Anything other than "traffic keeps flowing, the configuration is frozen" |
| 5. Log export | A proprietary format, or egress billing left unpriced |
| 6. At twice the traffic | A refusal to price the scenario you wrote |
| 7. Product and roadmap | A date with no contractual commitment |
| 8. Skills pool | A pointer back to the vendor's own teams |
| 9. References to call alone | A single reference, or all of them outside your scale |
| 10. Exit | An export whose format is not publicly documented |
Two procedural rules count as much as the questions. These ten lines form a separate lot, with its own weighting, otherwise they drown in the three hundred "compliant" answers of the functional grid. And every answer carries the name and role of whoever wrote it: an answer signed by a pre-sales engineer does not have the same standing as an answer signed by support.
The rest is a matter of verification. Put the two finalists' answers through the trial: an RFP answer is a promise, a trial is a fact. The decision deserves to be written from facts, if only to defend it in three years, when someone asks why that one was chosen.
Published in March 2026.
On the same subject