Write a software RFP that makes suppliers prove the outcome

“Does your platform support enterprise integration?” is an easy question for a supplier to answer. It is a difficult answer for a buyer to use.

One vendor may mean a maintained connector. Another may mean an API and several weeks of professional services. Both can say yes. The procurement team receives a completed spreadsheet without learning how either proposal will work in its environment.

A stronger software request for proposal starts with the outcome the organisation needs and asks each supplier to show how it will deliver it.

Describe one piece of work precisely

Take an employee leaving the business. The requirement is not simply “supports user provisioning”. It might be that a departure recorded in the authoritative system removes the person’s access to named applications, with failures visible to the support team.

That description immediately raises useful questions. Which applications are included? Which accounts remain local? What happens to existing sessions? What work falls to the customer? Those details make the response longer, but the comparison clearer.

The following is an example requirement for a fictional buyer. The 30-minute target is a chosen acceptance condition, not an industry standard.

RFP field	Example wording
Business outcome	Remove a departing employee’s access to the three applications named in Appendix A.
Trigger and target	A confirmed departure enters the HR system. Required account changes must complete within 30 minutes.
Demonstration	Use test accounts to show the source event, connector activity and resulting access in each application.
Failure case	Make one target unavailable. Show the alert, retry behaviour and support team’s route to resolution.
Response required	State supported versions, connector dependencies, session-revocation limitations, customer work and additional charges.
Acceptance	Each required access change meets the target; an incomplete change is visible and assigned. Identify any exception explicitly.

This gives suppliers room to explain their approach while making it harder to substitute a general capability statement for evidence. It also exposes a requirement that needs revision before contract negotiations begin.

This is a real distinction in identity procurement. Microsoft Entra’s provisioning documentation describes application-specific synchronisation intervals, retries after failed operations and differences in how target applications implement disabling and deletion. A procurement lead cannot infer immediate removal of access from the words “SCIM supported”. The application owner needs to demonstrate the end-to-end behaviour, including a failed update and any access that persists in the target system.

The hypothetical 30-minute requirement above is therefore a business requirement to prove or renegotiate, rather than an assumed feature of any named product. That distinction can prevent a technically accurate supplier response from becoming an operational misunderstanding.

Separate requirements from preferences

A mandatory requirement should describe something whose absence would prevent the purchase. Treating every preference as mandatory can exclude otherwise suitable options. Treating a critical dependency as a weighted preference can allow a high score elsewhere to conceal a fatal gap.

Use a small set of mandatory gates, then compare the qualified options. The software evaluation scorecard should reflect that order. A supplier that cannot meet the essential integration requirement should not win because its dashboard scored particularly well.

Allow “partially supported” and “requires custom work” as meaningful answers. A forced yes-or-no format can hide the very delivery assumptions the RFP is supposed to uncover.

Ask for evidence at the right stage

Not every question warrants a bespoke proof of concept. During initial screening, relevant documentation and a clear explanation may be sufficient. Reserve expensive demonstrations for the shortlisted suppliers and the requirements that carry the most uncertainty.

For those demonstrations, agree the task and evidence beforehand. A polished tour of a supplier’s preferred workflow is not a substitute for seeing your difficult case. Equally, do not introduce unannounced requirements midway through the process and then treat the resulting gaps as a fair comparison.

For software-security questions, the NIST Secure Software Development Framework provides a reference for development practices. Use relevant practices to shape specific evidence requests. A vendor’s assertion that it follows a framework is not itself evidence about the release you intend to buy.

Make the implementation answer part of the commercial answer

Ask suppliers to connect each proposed capability to delivery effort: configuration, licences, professional services, customer staffing and ongoing maintenance. Keep assumptions beside the price. For AI features, specify how model, feature and data-handling changes will be managed after purchase. Otherwise the least expensive proposal may simply contain the narrowest definition of the work.

Include the route out as well. A usable export, transition assistance and the cost of running two systems during migration belong in the assessment of lock-in, even when renewal feels distant.

The useful output of an RFP is an informed choice, not a fully populated questionnaire. If the answers still leave the team unable to explain what will work, what will cost extra and what could delay delivery, the document needs sharper questions rather than more rows.