Most CAFM RFPs get 80% polished vendor responses that all look the same. You end up picking on personality, demo quality, or price. A well-written RFP forces vendors to differentiate on the things that matter for your operation, and exposes the gap between "we support that" and "we do that well."
RFP structure that works
- Company background, who you are, estate size, pain points
- Project scope, modules in scope, user counts, sites
- Functional requirements, prioritised, not exhaustive
- Technical requirements, integration, hosting, security
- Implementation requirements, data migration, training, cutover
- Commercial requirements, pricing model, payment terms
- Vendor requirements, references, local presence, support SLAs
- Evaluation criteria, how you'll score responses
Be specific about scope
Vague scope = vague quotes. State clearly:
- Number of sites/campuses
- Asset count (rough)
- Concurrent user count (named users and technicians)
- Modules required (work orders? inventory? space? helpdesk?)
- Integration requirements (ERP, BMS, IoT, identity)
- Deployment model (SaaS / on-prem / private cloud)
Prioritise requirements (ruthlessly)
Every requirement marked "Must" is a requirement marked "not Must"
When 400 requirements all say "Must have," they rank vendors identically. Force prioritisation: Must (deal-breaker), Should (important), Could (nice), Won't (not this release). A focused RFP with 80 Must-haves and 120 Shoulds is vastly more useful than a 500-item wishlist.
Avoid checkbox requirements
"Must support work orders" is a useless question, every vendor says yes. Better:
- "Describe how your system handles work orders linked to multiple assets vs single asset, and how costs are allocated in each case."
- "Walk through how a reactive work order flows from helpdesk ticket through assignment, execution, completion, and closure with your SLA engine."
- "Show us a real configuration of your failure code framework with Problem/Cause/Action relationships."
Open questions force differentiation.
Technical requirements to include
- REST API availability and documentation quality
- Data export capability (can you get your data out?)
- Integration patterns for BC/SAP/Oracle ERP
- SSO and identity provider support
- Mobile app capabilities (offline, scanning, photo)
- Multi-site / multi-org data model
- Uptime SLA and support availability
Vendor diligence questions
- 3+ reference customers of similar scale and industry
- Local implementation partner presence
- Number of live implementations in your region
- Product roadmap for next 12-24 months
- Financial stability (for long contracts)
Publish your evaluation criteria
Vendors respond better when they know how they're being scored. Typical weighting:
- Functional fit: 30-40%
- Technical fit: 15-20%
- Vendor strength / references: 15-20%
- Implementation approach: 10-15%
- Commercial: 15-25%
Common RFP mistakes
- Copying a competitor's RFP. Every requirement inherited, none validated for your context.
- Too many requirements. 800-line spreadsheets nobody actually evaluates properly.
- No demo script. Vendors show their best cases, not your hardest ones.
- No pilot option. Sign multi-year deals without testing at scale.
- Ignoring total cost of ownership. Year 1 licence is not the cost, 5-year TCO is.
Conclusion
A good RFP is a strategic tool, not a questionnaire. Scope tightly, prioritise ruthlessly, ask open questions, publish criteria. Do that and your shortlist of 3 vendors will actually differ from each other on the things that matter. That makes the final decision easier, and the ultimate go-live more successful.
Written by Muhammad Abbas
Enterprise integration specialist. Independent CAFM vendor selection guidance.
