CMMS RFP Guide and Template

Introduction

A CMMS RFP should help a buying team compare solutions and implementation partners against the operating problem. It should also help responsible vendors identify assumptions and decline a poor fit. A document with 500 yes/no features does neither.

The strongest RFP combines context, scope, outcome, end-to-end scenarios, data/integration/security requirements, implementation responsibilities, commercial structure and a scoring method. It gives all vendors the same evidence request and separates current capability from roadmap promises.

Table of Contents

1. Prepare before issuing the RFP
2. Recommended RFP structure
3. Scenario-based requirements
4. Data, integration and security
5. Implementation and support
6. Pricing template
7. Demo and scoring
8. Due diligence and selection
9. FAQs

Prepare Before the RFP

Confirm the problem and sponsor

Describe current maintenance workflow, operating consequences and why change is funded now. Assign a sponsor and process owner. If the organization cannot agree on scope or decision rights, a public RFP will generate contradictory answers.

Map stakeholders

Include maintenance, technicians, operations, reliability/engineering, stores/procurement, IT/security/data, finance and legal as appropriate. Define who evaluates which sections.

Profile data and systems

Estimate sites, assets, users, PM, open work, parts, history and attachments. Inventory ERP, identity, production/IoT, documents and analytics integrations. Vendors need this to price responsibly.

The Procurement Process

Publish timetable, question process, response format, demo stages, decision authority and confidentiality. Give vendors enough time for a complete response.

Recommended RFP Structure

1. Organization and operating context

• Industry and locations in scope.
• Maintenance organization and shifts.
• Asset classes/criticality context.
• Current systems and pain points.
• Relevant connectivity/mobile constraints.
• Regulatory/security context without disclosing unnecessary sensitive detail.

2. Objectives and measures

Examples: establish one work system, improve PM control, create asset history, support mobile technicians, connect maintenance demand to parts/procurement. Include baselines where reliable. Do not prescribe guaranteed improvement.

3. Scope

• Sites, users/roles, approximate assets.
• Processes/modules in first release.
• Integrations and migration.
• Languages, time zones, environments.
• Explicit exclusions and future phases.

4. Response instructions

Require vendors to mark:

• Available standard now.
• Available by configuration.
• Requires integration.
• Requires custom development.
• Third-party dependency.
• Roadmap/not currently available.
• Not supported.

Ask for explanation and evidence on critical items, not marketing links alone.

5. Functional scenarios

Use end-to-end cases described below.

6. Data/integration/security/non-functional

Evidence and Specialist Review

7. Implementation/support

Require method, deliverables, roles, assumptions, references and ongoing service.

8. Commercial response

Use a normalized template and pricing validity.

9. Contract and due diligence

Legal, privacy, security, service, data and exit questions.

Scenario-Based Requirements

Corrective work

A production operator reports an abnormal condition against a scanned asset with evidence. Maintenance screens the request, sets consequence-based priority, plans labor/parts/safety, schedules access with production, assigns a technician, records findings and closes after supervisor review. Demonstrate exceptions for unavailable parts and expanded scope.

Preventive work

A critical PM is generated from a governed schedule, includes versioned job steps/readings, is executed on mobile, creates follow-up corrective work from an out-of-limit finding and preserves evidence. Show deferral authorization and schedule effects.

Spare part and procurement

A planner checks/reserves a part. The part is unavailable, creating a requisition or ERP transaction. Demonstrate issue/return, synchronization, error handling and cost visibility boundaries.

Multi-site control

Corporate users see approved roll-up data while site roles see local assets/work. A standard job plan is reused with controlled local variation. Demonstrate permissions, reporting and data governance.

Contractor work

External work is requested, scoped, approved, scheduled, documented and accepted with appropriate restricted access.

Condition event

A supported reading/alert is reviewed, linked to asset history and converted into inspection/work. Show how the outcome is captured.

Audit/investigation

An authorized user retrieves asset work, PM revision, readings, parts, approvals and record changes for a defined period.

Have vendors demonstrate using a controlled sample of buyer data. Do not accept a generic polished demo as proof of critical workflows.

Data, Integration and Security Questions

Migration

• Supported entities and import tools.
• Required templates and customer responsibilities.
• Trial loads, validation, error and reconciliation.
• Attachment/history limits.
• Open-work and PM cutover.
• Archive/export options.

Integration

For every interface, request:

• Architecture and supported API/connectors.
• Data objects and direction.
• Authentication and authorization.
• Frequency, volume and limits.
• Monitoring, retry, error workflow and audit.
• Environments/testing.
• Ownership and ongoing support/pricing.
• Version/change policy.

Security and privacy

Qualified reviewers should assess identity, MFA/SSO, RBAC, tenant/site segregation, encryption, logging, backups/recovery evidence, vulnerability/patch process, incident handling, data location/subprocessors, support access, retention, export/deletion and applicable contractual commitments. Ask for evidence under NDA where appropriate. Do not rely on a one-word “compliant.”

Non-functional

• Availability/support targets and measurement.
• Performance with expected records/users.
• supported browsers/devices and mobile/offline behavior.
• scalability/growth.
• accessibility and language.
• backup/recovery objectives.
• maintenance/release windows.
• data portability.

Implementation and Support Response

Require:

• Discovery and future-process approach.
• Project plan and dependencies.
• Named vendor/customer roles.
• Configuration and decision log.
• Migration/integration/test/cutover method.
• Role-based training and site-champion model.
• Stabilization and adoption support.
• Change request and scope control.
• Support channels/hours/severity/escalation.
• Release management.
• References with comparable complexity.

Ask vendors to identify the top five risks in the buyer’s stated scope. A thoughtful risk answer can be more revealing than a “fully compliant” matrix.

Pricing Template

Request three-year or five-year lifecycle cost using the same assumptions:

• Subscription/license by role/site/asset/module.
• Environments, storage, API/notification/usage.
• Discovery/design.
• Configuration/project management.
• Migration by data entity/volume.
• Integrations individually.
• Training/change and travel if any.
• Cutover/stabilization.
• Support tiers.
• Optional/future items.
• Taxes/currency/payment and validity.
• Renewal/increase/overage.
• Customer internal requirements.
• Data export/exit assistance.

Separate fixed, estimated and consumption-based amounts. Require assumptions and exclusions.

Demo and Scoring

Weight by decision importance

Example only:

• Functional scenarios 25%.
• Field usability 15%.
• Data/integration 15%.
• Security/non-functional 10%.
• Implementation/support 15%.
• Architecture/product fit 10%.
• Commercial/TCO 10%.

Mandatory gating criteria must be enforced; a vendor failing a critical security or work-control requirement should not win through unrelated points.

Control the demo

• Same scenarios and time for shortlisted vendors.
• Buyer users perform tasks.
• Record standard/config/integration/custom status.
• Capture unanswered questions and evidence.
• Test exception paths and offline/sync where relevant.
• Score independently before consensus.

Normalize references

Ask reference customers about scope, data condition, implementation responsibilities, adoption, support, changes, unresolved issues and whether commercial expectations matched reality. Respect confidentiality.

Selection and Due Diligence

Before award:

• Resolve critical gaps and roadmap dependencies contractually or remove them from assumed scope.
• Validate security/legal/privacy evidence.
• Confirm implementation team and subcontractors.
• Reconcile final scope, plan and TCO.
• Define acceptance criteria and change control.
• Confirm data ownership/export and exit.
• Document decision rationale, tradeoffs and risks.

A proof of concept is justified for high-risk integrations, offline workflows or complex data—not as an unpaid mini implementation.

Common RFP Mistakes

• Issuing before internal scope agreement.
• Copying another company’s feature list.
• Requiring every feature as mandatory.
• Asking yes/no questions without evidence.
• Letting vendors choose all demo scenarios.
• Comparing license price instead of lifecycle scope.
• Treating future roadmap as current capability.
• Ignoring customer responsibilities and internal effort.
• Excluding technicians from evaluation.
• Selecting first, then discovering security/data constraints.

FAQs

How long should a CMMS RFP be?

Long enough to communicate context, scenarios, evidence and commercial structure. Remove generic questions that do not change selection.

Should an RFI come first?

Use an RFI when market/options are unclear. A focused discovery can also narrow scope before an RFP.

How many vendors should be shortlisted?

Enough for meaningful competition within evaluation capacity. The number depends on procurement policy and market; avoid superficial demos from too many.

Should vendors receive sample data?

A controlled, sanitized sample improves evidence. Follow security/confidentiality and minimize sensitive information.

How should customization be scored?

Assess business need, development/upgrade/support risk, cost and alternatives. Distinguish configuration from custom code.

What belongs in acceptance criteria?

Tested scenarios, data reconciliation, integrations, permissions, performance, training/cutover deliverables and resolved critical defects.