What the Vendor Isn’t Telling You — And What the Fire Department Isn’t Saying Either

I have been on both sides of this conversation.

I have been the battalion chief sitting across the table from a vendor, watching a demo, trying to figure out whether what I was seeing was real, whether it would actually work in my department, and whether the person across from me could be trusted.

And I have been the person on the other side of that table — the vendor — trying to explain a product to a department that came in with expectations shaped by a previous conversation I was not part of, a competitor’s demo I had not seen, and a budget process I did not fully understand.

Both experiences were humbling. Both taught me things the other side could not have taught me. And together they gave me a perspective on the fire department and vendor relationship that I have not seen written down anywhere — which is why I am writing it now.

Fire department technology investments range from a few thousand dollars to hundreds of thousands to — in the case of major platform deployments — well into the millions. I have seen purchases at every point on that spectrum. What I can tell you is that the complexity of the vendor relationship tends to scale directly with the size of the investment, and so does the cost of getting it wrong. Whether your department is evaluating a targeted CRR tool or a region-wide platform, the conversations in this article apply. The bigger the number on the contract, the more they matter, for both sides.

This article is primarily for fire departments. But it is informed by genuine time in both roles, and I want to be honest about what both sides experience — because understanding the vendor’s reality is one of the most practical things a department can do to protect its own investment.

The Phrase That Cost Me More Than I Want to Admit

“We can do that.”

I heard this phrase more times than I can count during my career evaluating technology for our department. And I want to be honest about something: the problem was not always the vendor.

The problem was that I did not follow up.

When a vendor said “we can do that,” I nodded. I wrote it down. I moved on to the next question. What I did not do — what I wish I had done every single time — was ask the follow-up questions that would have told me what that phrase actually meant.

Does it do that right now, today, in the current version of the product?

Is it something that is being built and will be available by the time we go live?

Is it a feature that requires additional configuration or customization — and if so, what does that cost?

Is it on your roadmap, meaning you intend to build it but have not yet?

Or are you telling me you can do it because you believe it is technically possible, but nobody has actually asked for it before?

Those are five completely different answers. All of them can honestly be delivered as “we can do that.” And I never asked which one applied.

Before going further, I want to say something clearly — because this article could easily be read as an indictment of vendors, and that is not what it is.

In my experience on both sides of this relationship, the vast majority of vendors are honest. They want their product to be fully implemented and genuinely used. They want good outcomes for the departments they work with. They want the relationship to work. A vendor whose customers succeed renews contracts, generates referrals, and builds a reputation in a fire service community that is smaller and more networked than most people realize. Honest vendors know this.

The problems I have described — and the ones I will describe — are almost never the result of bad faith. They are the result of gaps in communication, differences in expectation, and questions that were not asked clearly enough or answered specifically enough. Understanding that changes how you approach these relationships. The goal is not to go into a vendor relationship looking for deception. The goal is to build the kind of clarity that lets honest vendors do their best work for your department.

That starts with getting everything that matters in writing. Every capability your department is counting on needs to be documented specifically before the contract is signed. Not in a demo. Not in a follow-up email that says “per our conversation.” In the contract, or in a written addendum to it, with clear language about what exists today, what requires additional cost, and what timeline applies to anything that is not yet built.

If a vendor will not put it in writing, that is the answer to your question.

What It Felt Like on the Other Side

When I moved into the vendor world and started working directly with fire departments as customers, something shifted in how I understood these relationships.

I walked into conversations with departments that had been burned before. Chiefs who had signed contracts based on demos that did not match what was delivered. Prevention officers who had spent months trying to make a system work that was never designed for what they needed. Administrators who discovered, after the contract was signed, that getting their own data out of the system was going to cost them.

I understood their skepticism immediately. I had felt it myself on the other side.

But I also saw, from the vendor side, how often the frustration went both ways. Departments that signed contracts without assigning anyone to manage the implementation. Staff who resisted new systems because nobody had communicated why the change was happening. Projects that expanded significantly in scope after the contract was signed, without anyone acknowledging that this represented additional work. Departments that went silent for weeks during critical phases of implementation and then expressed frustration that the timeline had slipped.

Neither side was entirely wrong. Neither side was entirely right. And in almost every difficult relationship I witnessed or experienced, the problems had roots that went back to the beginning — to conversations that were not specific enough, expectations that were not documented, and questions that were not asked.

Who Are You Actually Talking To?

One of the most important things I learned — first as a chief and then as a vendor — is that the person who sells you the product is almost never the person who implements it, supports it, or maintains it after go-live.

This is not a criticism of sales representatives. It is just how technology companies are structured. Sales, implementation, and support are separate functions with separate teams, separate knowledge bases, and sometimes genuinely different understandings of what the product does and how it works in practice.

The sales representative knows the product at the level of a compelling demonstration. The implementation team knows it at the level of configuration and deployment. The support team knows it at the level of what breaks and how to fix it. These are three different bodies of knowledge, and they do not always overlap as fully as you would hope.

As a chief, I built relationships with sales representatives that I assumed would carry through the entire vendor relationship. They did not. Sales representatives move on, change territories, get reassigned. The goodwill built during the sales process does not automatically transfer to the people who will actually be responsible for making your implementation work.

What I know now, having been on the other side: ask to meet the implementation team before you sign. Ask who specifically will be assigned to your project. Ask what their current workload looks like. Ask what the escalation path is when problems arise — and they will arise.

And ask what support looks like after go-live. Not during implementation, but twelve months later when your system is live and you have a problem. Is there a dedicated account manager? A general support line? A ticket system? What are the response time commitments? What is covered under your contract and what triggers an additional charge?

The most important question you can ask a vendor is not about features. It is: who will I be talking to in a year when I need help, and how do I reach them?

Data Ownership: The Question I Wish I Had Asked

Here is one I did not fully understand as a chief, and that I became acutely aware of as a vendor.

Your department generates data every day. Incident data. Inspection data. Assessment data. Community risk intelligence. Training records. Response data. When that data lives in a vendor’s platform, a question that feels abstract during procurement becomes very concrete when the relationship ends.

Who owns it?

In most technology contracts, the answer is not as clear as it should be. Vendors typically assert significant control over data stored in their systems. Some contracts are explicit about this in ways that would alarm most chiefs if they read them carefully. Others are ambiguous in ways that become very clear — and very costly — when a department tries to leave.

If you decide to switch vendors, can you export your complete data in a usable format? If the vendor is acquired by a competitor, what are your rights? If the contract ends for any reason, what happens to five years of community risk data your department collected?

These are not hypothetical scenarios. Vendors get acquired. Companies fail. Departments outgrow platforms. And in each of these situations, departments that did not address data ownership during procurement find themselves negotiating from a position of weakness — or simply losing access to data that belongs to their community.

Data ownership and portability must be addressed explicitly in the contract before you sign. Your department should own its data, full stop. The contract should specify that you can export complete data in a standard usable format at any time, at no additional cost, within a defined timeframe. It should specify what happens to your data if the contract ends for any reason.

If a vendor pushes back on these terms, pay close attention to what they say and why. That conversation will tell you a great deal about the relationship you are about to enter.

The Implementation Gap

Demos are designed to show products at their best. Implementations are where products meet operational reality — and that gap is where most frustrations are born.

I have seen this from both sides. As a chief, I watched systems that looked seamless in a demo become complicated in practice because our data was messier than anyone anticipated, our staff had less time for training than we planned, and our internal processes did not map cleanly onto the way the system was designed to work.

As a vendor, I watched departments go into implementations without a clear internal owner, without staff who understood why the change was happening, and without realistic expectations about what the transition would require from them.

The honest truth about implementations is that they are almost always harder than the demo suggested, take longer than the timeline projected, and require more from the department than anyone communicated during the sales process. This is not necessarily bad faith. It is the nature of complex technology deployments meeting real organizational constraints.

Several things departments consistently underestimate going in:

The internal champion requirement is real. A successful implementation needs someone with authority, time, and genuine commitment. This person needs to be identified before the contract is signed. Implementations without a clear internal owner struggle, and the vendor cannot compensate for this no matter how good the product is.

Data migration is never automatic. If you are moving from one system to another, the assumption that data will transfer cleanly is almost always wrong. Ask specifically how migration will be handled, who is responsible, what the process looks like, and what happens if data is lost or corrupted.

Staff training is not a one-time event. Training during go-live week is not sufficient. Staff turn over. Systems update. Workflows change. What does ongoing training look like? What does it cost? What is available when a new employee joins a year after implementation?

Timeline projections are almost always optimistic. Ask how long implementations of similar scope have actually taken, not how long they are projected to take. Then build in buffer.

The Reference Check You Are Not Doing Correctly

Most departments conduct reference checks as a formality. They ask the vendor for two or three references, have brief positive conversations, and treat it as a box to check.

That is not a reference check. That is a testimonial.

A genuine reference check means talking to departments that are similar to yours in size, call volume, and use case. It means asking specific questions about the implementation experience, not just the product. It means asking what they wish they had known before signing. It means asking whether they would make the same decision again — and listening carefully to any hesitation.

It also means finding references the vendor did not provide. Ask in your professional networks. Ask your state fire chiefs association. Reach out directly to departments you know are using the product. The conversations you have with departments the vendor did not recommend will tell you more than the ones with departments they did.

Questions worth asking every reference: How long did implementation actually take compared to what was projected? Did the product do everything you were told it would do during the sales process? What does support look like day to day? What is your biggest ongoing frustration? What do you wish you had included in your contract?

The Frustrations Vendors Will Never Tell You About

Having worked on the vendor side of this relationship, there are things vendors experience that departments almost never hear — and understanding them makes departments significantly better partners.

Vendors invest heavily before you sign. Procurement processes are expensive — demos, proposals, site visits, follow-up conversations. They take significant time and resources. Departments that bring genuine clarity about their timeline and intent get better engagement than those who are still figuring out whether they are serious buyers.

Implementation failures are rarely the vendor’s fault alone. The most common causes include departments that never assigned a real internal champion, staff who resisted adoption because leadership did not communicate why the change was happening, data that was far messier than the department represented, and scope that expanded after the contract was signed. Vendors see this pattern repeatedly and have limited ability to compensate for it.

Scope creep is real. When a department asks for something that was not in the original contract — even something that seems small — it represents real cost. The tension this creates is almost always the result of unclear contract language rather than bad faith on either side. Both parties are better served by contracts that are specific about what is included and what triggers additional cost.

And here is what I want to say clearly one more time: most vendors want you to succeed. This is not a courtesy statement. It is a business reality. A department that uses a product effectively, renews its contract, and recommends the vendor to peers is worth far more than the initial contract value. Most vendors are genuinely motivated to make your implementation work — and they deserve a department partner who is equally committed to making it succeed.

What I Know Now That I Did Not Know Then

Having been the chief and the vendor — having asked the wrong questions and answered them, having signed contracts I did not fully understand and been on the other side of contracts that were not specific enough — here is what I would tell every fire department going into a vendor relationship.

Get every material commitment in writing before you sign. Not in a demo. Not in a follow-up email. In the contract.

Ask “we can do that” follow-up questions every single time. Is it built today? Does it cost extra? When will it be available? What happens if it is not ready by go-live?

Meet the implementation team before you sign. Build a relationship with the people who will actually do the work, not just the people who sold you on it.

Define data ownership explicitly. You own your data. Make sure the contract says so.

Assign a real internal champion and protect their time. The vendor cannot make your implementation succeed without genuine engagement from your side.

Find your own references. The departments the vendor recommends are happy customers. Find the ones who had a harder experience and learn from them too.

Treat the relationship as a partnership — and verify everything in writing. The best vendor relationships in the fire service are built on genuine mutual investment in outcomes. They are more common than the horror stories suggest. Most vendors come to the table wanting to do right by your department. The clarity and documentation I am advocating for is not about protecting yourself from dishonest vendors. It is about giving honest vendors the foundation they need to deliver on what they genuinely intend to provide.

What This Is Really About

Most vendors in this space are good people doing difficult work. They are navigating complex products, limited implementation resources, and customer expectations that are sometimes genuinely hard to meet regardless of how good the product is. They deserve partners who are as prepared and committed as they are.

The fire department and vendor relationship matters because technology is one of the most significant investments many departments make in their CRR capacity. When these investments work, they extend the reach of prevention programs, improve community risk intelligence, and help departments serve their communities more effectively.

When they do not work — when departments feel misled, when data disappears, when systems sit unused — the cost is not just financial. It is the community risk reduction capacity that was supposed to come from that investment and did not.

I have been on both sides of this relationship. I know how it feels when it goes wrong and what it looks like when it goes right.

The difference, in almost every case, comes down to clarity at the beginning — about what is being bought, what is being delivered, who is responsible for what, and who owns the data that will outlast any contract.

Ask the questions. Get the answers in writing. Build the partnership.

Your community is counting on it.

Brent Faulkner, MAM, FO, is the CEO and Founder of Virtual CRR Inc.
A retired Battalion Chief from Anaheim Fire & Rescue, Brent brings 28 years of fire service experience, including leadership in structure fires, wildland operations, hazardous materials response, EMS incidents, and specialized rescue operations. He also served 17 years on a Type 1 Hazardous Materials Response Team.

A defining moment in Brent’s career came while leading Critical Infrastructure Protection (CIP) efforts at a DHS-recognized Terrorism Fusion Center. There, he oversaw initiatives to safeguard critical infrastructure from terrorism, natural disasters, and emerging threats — an experience that shaped his passion for Community Risk Reduction and ultimately led to the creation of Virtual CRR.

Brent holds a Master’s Degree in Management, a Bachelor’s in Occupational Studies, and Associate Degrees in Hazardous Materials Response and Fire Science.