What to Know Before Your First CMMS Vendor Call

A CMMS vendor will probably have questions for you.

How many users?

How many sites?

What are you using today?

Why are you looking for a CMMS?

What needs to improve?

Those are reasonable questions. The answers help the vendor understand whether its software might fit and what product, services and pricing may apply.

You should arrive with questions too.

The first vendor conversation is your chance to explain enough about the operation for the vendor to respond intelligently, learn how the vendor approaches your requirements, and decide whether a deeper evaluation is worth your time.

You do not need a finished RFP.

You do need to know your operation well enough to keep the conversation connected to it.

Have a one-page picture of the operation

Before the call, write down the basic shape of the maintenance environment.

You should be able to describe:

• number of facilities or sites
• approximate number of technicians
• other people who will need system access
• major asset types
• how maintenance requests arrive today
• how work gets assigned
• how preventive maintenance is scheduled
• how technicians receive and record work
• how parts and inventory are handled
• what managers need to report on
• systems the CMMS may need to connect with
• important mobile or offline requirements

This does not need to be polished.

Its purpose is to give the vendor enough context to understand the operation behind the software search.

If you have already built your CMMS requirements, use them. Your requirements should come from the way the operation works rather than from a vendor feature list.[2][3]

Be able to explain why you are looking

“We need a CMMS” does not tell the vendor much.

Describe what is happening now.

For example:

• Work requests arrive through email, phone calls and hallway conversations.
• Technicians have trouble seeing current priorities in the field.
• Preventive maintenance schedules are maintained in spreadsheets.
• Asset history is incomplete or difficult to retrieve.
• Parts usage is not consistently connected to work orders.
• Management cannot easily see backlog or maintenance performance across sites.
• The existing system is difficult for technicians to use.
• The organization is adding facilities and the current process is becoming harder to manage.

Specific operating conditions give the vendor something useful to respond to.

They also give you something useful to evaluate later.

If a major reason for the project is that technicians cannot reliably receive or close work in the field, mobile workflow deserves more attention than an impressive executive dashboard.

Know what matters most

Bring a short list of your highest-priority requirements.

Five to ten is enough for the first conversation.

Separate them into:

Must support

These are requirements that would materially affect whether the system can work in your environment.

Important

These matter to the evaluation but may allow different approaches.

Useful

These would be valuable but should not distract from more important requirements.

The purpose is prioritization.

A vendor may have hundreds of capabilities. Your operation does not value all of them equally.

Defining priorities before vendor conversations makes it easier to notice when the discussion moves toward impressive capabilities that do not solve an important problem for your team.

Know your likely scope

You do not need final numbers, but bring reasonable estimates.

People

How many people may need to:

• administer the system?
• plan or supervise maintenance?
• perform maintenance?
• submit requests?
• view information or reports?

Ask the vendor which of those people require paid licenses.

Sites

How many facilities, plants, properties or operating locations are in scope now?

Could more be added later?

Assets

What major asset groups will be managed?

You may not need an exact asset count on the first call, but know whether you are talking about hundreds of assets at one facility or a large distributed asset base across many locations.

Integrations

Identify systems that may need to exchange information with the CMMS.

Examples include:

• ERP
• purchasing
• inventory
• GIS
• identity / SSO
• business intelligence
• accounting
• sensors or condition-monitoring systems

Data

Know what information already exists and where it lives.

Examples:

• asset lists
• location hierarchies
• preventive maintenance schedules
• parts lists
• historical work orders
• meter readings
• vendor records

This begins to define both software scope and implementation scope. Documented purchases show how differently those two amounts can be structured in What Does a CMMS Actually Cost?.

Have a preliminary cost profile

You do not need to tell a vendor what you are willing to spend before you understand what it will cost to support your requirements.

You should, however, know what needs to be priced.

Your preliminary cost profile should include:

• expected paid users
• requester access
• sites
• required product tier or capabilities
• implementation
• data migration
• integrations
• training
• support
• recurring services
• likely expansion

Ask how the vendor prices each part.

Also ask for enough information to eventually compare:

Year 1 cost

Ongoing annual cost

Three- or five-year total

For a deeper framework, see What Should a CMMS Cost?

Expect the vendor to qualify you

The vendor is evaluating the opportunity while you are evaluating the software.

Expect questions about:

• your current process or system
• problems you are trying to solve
• number of users
• number of sites
• required capabilities
• integrations
• implementation timing
• who is involved in the decision
• how the buying process will work
• budget or expected investment
• competing systems you are considering

You do not need to treat this as an adversarial exercise.

Good answers can help the vendor determine whether there is a fit and prepare a more relevant next conversation.

But you also do not need to invent answers.

If the budget has not been established, say that.

If the user count is still being determined, provide the best current estimate and identify it as an estimate.

If the decision process is still taking shape, explain what is known.

Accurate uncertainty is more useful than false precision.

Questions worth asking on the first call

The first call should help you decide whether a deeper evaluation is warranted.

You do not need to interrogate the vendor with a 50-question checklist.

Start with questions that clarify fit.

Product fit

• Based on what I have described, what part of your product would you expect us to use?
• Which of our requirements appear straightforward in your system?
• Which would require configuration, another product tier, an add-on or custom work?
• Are any of these requirements something you do not currently support?
• What user types would require paid licenses?

Similar operations

• Do you support organizations with a similar number of users, sites and assets?
• Do you have customers with similar maintenance workflows or operating environments?
• Which parts of our use case tend to require the most planning?

A familiar industry logo is useful context, but operational similarity matters too.

A maintenance team can share an industry with another customer while having a very different asset structure, workforce, workflow or integration environment.

Implementation

• Who normally handles implementation?
• What work would your team do?
• What work would our team need to do?
• How is existing asset and maintenance data typically imported?
• What affects implementation time and cost?
• What training is included?
• What happens after go-live?

Do not wait until contract review to discover that important implementation work belongs to your team.

Integrations

For every important integration, ask:

• Is this available today?
• Is it included in the product tier we would use?
• Is it a standard integration or a custom project?
• Does it require an API or third-party product?
• Is there an additional recurring cost?

“Can integrate with” is the beginning of the conversation.

You need to understand what the integration would require in your environment.

Pricing

You may not receive a final quote on the first call.

You should be able to learn how pricing works.

Ask:

• What is the primary pricing unit?
• Which users are paid?
• Are there minimum user counts?
• Which capabilities affect the product tier?
• What is normally charged separately?
• How is implementation priced?
• Are integrations additional?
• What should we expect to pay again each year?
• What typically causes cost to increase as a customer expands?

This information will make the eventual quote easier to understand. It can also help to see what other organizations bought before the call, in the public CMMS procurement records.

Ask what is available today

Software conversations often include future plans.

When a requirement matters to the buying decision, establish whether the capability:

• exists in the current production product
• requires configuration
• requires an add-on
• requires custom development
• is provided through a partner or third party
• is planned for a future release

A roadmap can be useful information.

Record it as roadmap information.

Do not record planned functionality as a capability you have already verified.

This distinction becomes especially important during the demo.

Indian River County, Florida made it explicit in its 2026 CMMS procurement. Vendors were required to demonstrate released production software, while roadmap or future functionality had to be clearly identified.[1]

That is a useful standard even if your organization is not running a formal RFP.

Do not schedule the demo blindly

A common next step after an introductory call is a product demo.

Before agreeing to the demo, decide what you want the vendor to show.

Give the vendor a few real scenarios from your operation.

For example:

Scenario 1: A maintenance request becomes completed work

A production employee reports a problem. A supervisor reviews and prioritizes it. A technician receives the work in the field, sees the asset history, records labor and parts, adds a photo and closes the job.

Scenario 2: Preventive maintenance becomes due

A PM is triggered. Work is assigned. The technician follows the required procedure, records the result and identifies a follow-up repair.

Scenario 3: A manager needs an answer

A maintenance manager wants to see overdue work, PM compliance or recurring problems on a critical asset.

The details should come from your operation.

Indian River County's 2026 procurement required vendors to follow defined demonstration scenarios using live production software and emphasized realistic daily use by technicians and supervisors.[1]

Your process does not need to be that formal.

The principle is useful: give the vendor something real to demonstrate.

Article #8 will cover how to build and run the CMMS demo in detail.

Keep a vendor call record

After each call, record the same basic information.

Do this immediately after the call.

After several vendor conversations, small details become difficult to remember and similar products begin to blur together.

A consistent record also gives you something to compare before investing time in deeper demos.

What should you leave the first call knowing?

Before moving forward, you should have a clearer answer to these questions:

1. Does this vendor appear capable of supporting the important parts of our operation?
2. Which requirements still need to be proved?
3. Which product tier, modules or services appear relevant?
4. How does the vendor charge?
5. What implementation work is likely?
6. Which integrations need deeper investigation?
7. Did the vendor identify anything as custom, third-party or roadmap functionality?
8. What should the vendor show us next?

You probably will not know whether this is the CMMS you should buy.

That is fine.

You should know whether the next conversation is worth having.

And if the next conversation is a demo, you now have something much better than a request to “show us the software.”

You have an agenda.

Next → The CMMS Demo Checklist