A vendor demo is a controlled environment, and vendors in this space have spent years getting good at it. The interface is clean, the scenarios are preselected, and the reference call happens with someone who finished onboarding six months ago. What the demo rarely surfaces is how the software behaves when a shift trade creates a certification mismatch, or what happens when the department's pay code logic doesn't map into the system's native rules. These issues generate payroll corrections and grievances. The questions below are designed to surface them before anything gets signed.
Several of the most widely used staffing platforms in the fire service were founded by firefighters. TeleStaff traces back to Anaheim Fire Department. CrewSense came out of Oregon. Aladtec has similar roots. After private equity acquired them, these products gradually expanded into other markets, support teams lost their fire service context, and the operational specificity that made them useful eroded over time.
Despite these purpose-built origins, many platforms now miss the mark on the specifics that matter most. A department calling support about a callback gets a rep asking what a callback is. Apparatus-level minimum staffing, 24/48 and 48/96 shift patterns, Kelly and debit days, certification and qualification matching on trades, and acting pay automation need to be native to the system. When those rules live as workarounds rather than core logic, they create a single point of failure. One payroll admin on vacation can mean payroll waits. A staffing expert who retires early can mean the department pays overtime to bring them back just to fix the issues that follow.
The more useful question to put to any vendor is not what percentage of their customer base is fire departments. It is whether their support team can triage a callback dispute, understand the department's specific CBA rules, and resolve the issue without escalating to someone who has never worked in the fire service. For a deeper look at how firefighter shift patterns interact with FLSA overtime thresholds, the implications run further than most departments realize at contract signing.
A fire department signing a five-year contract is making a long bet on what that vendor looks like in year four. When private equity acquires a software vendor, price increases tend to follow, support quality tends to decline, and the asset eventually gets sold or absorbed into something larger. Departments mid-contract find themselves working with an organization that never pitched them.
ESO Solutions is the most visible example. Backed by Accel-KKR and later Vista Equity Partners, ESO acquired FIREHOUSE Software, Emergency Reporting, and several other platforms, then shut down or consolidated them. Departments that had relied on Emergency Reporting for over a decade reported cost increases of 110% or more. In January 2026, US Senators Klobuchar and Marshall formally called on the DOJ and FTC to investigate ESO's consolidation of fire department software. The answer to the ownership question is publicly verifiable before anyone signs anything.
When a vacancy opens at 0700, the question is whether the hiring engine follows the department's actual callback rules as written. Voluntary lists before mandatory holds, seniority and certification eligibility checked at every tier, callout sequenced by the CBA. A platform that broadcasts an open shift and fills the seat on first-come leaves the department's written rules unenforced, and that is where grievances start.
The audit trail matters just as much. When a grievance gets filed over a callout, the question is whether the system captured every action taken, every rule applied, and every decision made before the final assignment was recorded. A hiring engine that cannot produce that record puts the battalion chief's word against the firefighter's in any arbitration. For a closer look at how callback compliance connects directly to overtime costs, the two problems are rarely as separate as they appear on a budget sheet.
On average, more than 80% of a given city's pay codes belong to the fire department alone, far more than police or any other government agency. Acting pay, specialty certification differentials, LSA overtime calculations, Kelly day adjustments, and union agreement terms all have to interact correctly for a timecard to be accurate. The One Big Beautiful Bill, signed into law in July 2025, introduced new federal reporting requirements that require departments to separately identify and report FLSA-required overtime premium from CBA-required overtime on payroll records, adding another layer of complexity to an already complicated payroll environment.
Pay code assignment automated in the scheduling layer means the correct code fires based on who is working, what position they are filling, and what their hours balance looks like. The timecard arrives at payroll already correct. Pay code logic managed downstream and reconciled after the fact produces a correction cycle that repeats every period. Battalion chiefs were not hired to sit behind a desk and audit pay codes. The question worth putting to any vendor is where that logic lives in their system, and whether they can demonstrate how it behaves on a specific edge case from the department's own CBA. For a deeper look at how pay code errors compound across a department's payroll cycle, the downstream consequences run further than a single corrected timecard.
Some fire departments run a standard 24/48 or 48/96. Others have negotiated patterns that don't fit any standard template, a 66-hour workweek with Kelly days layered on top, or a debit day structure tied to a modified 24/72. Departments that explore switching to a new shift pattern often don't anticipate how significant the implementation fees can be when a vendor has to build new rules or schedule configurations from scratch.
Platforms that require a vendor engineering ticket and a change order for anything outside their preset templates transfer the cost of that update to the department in time and budget every time the MOU changes. Over a five-year contract, the accumulated cost of that dependency is worth calculating before signing. For a fuller picture of how schedule pattern decisions interact with overtime budgets and staffing costs, the financial implications of a pattern change run deeper than the headcount math alone.
Departments carry years of staffing history, payroll records, shift trade logs, and audit trails inside their platform. Some vendors treat that data as theirs rather than the department's. That position affects more than what happens at the end of a contract. It affects the ability to connect systems via API, pull data for custom reports, and move freely between vendors without losing years of operational records.
The questions worth asking before signing are what data the department can access at any point during the contract, in what format, what the vendor needs access to and why, and whether there is a fee to export records at renewal or departure. Requiring vendors to sign or amend a data sharing agreement that specifies exactly which fields they can access, and how, is a practical step departments can take before anything is finalized. As Alpine Software notes in their guide to data ownership in fire departments, a complicated answer to these questions during the evaluation is itself a data point.
The vendor relationship changes after the contract is signed. The contact who understood the department's specific setup during procurement gets replaced, feature requests discussed in demos disappear into ticket queues, and response times stretch. Multi-day response windows on critical issues are common enough in this industry that they have become a primary driver of vendor switches.
Before signing, three things are worth confirming in writing:
A support team that doesn't know what a callback is, or isn't familiar with the department's CBA, adds time and frustration to every issue rather than resolving it. The Sourcewell guide to modernizing fire rescue operations outlines what a functional vendor relationship looks like beyond the sales process, and the gap between that standard and what most departments experience is where switches get decided.
A vendor that answers all of these questions directly, before the demo ends, is giving the department something useful. The answers sort vendors faster than any feature comparison will.
Stationwise was built specifically for fire departments, prices by battalion rather than per user, and handles its own support with a team that knows the fire service. Every callback runs through a rules-based hiring engine that enforces the department's actual CBA, pay code logic is automated in the scheduling layer, and schedule patterns including custom configurations are built without vendor engineering tickets. When Fresno County Fire Protection District needed a 66-hour workweek pattern that no off-the-shelf system could support, Stationwise built it without breaking pay code logic or FLSA tracking. Their battalion chiefs now save 2 to 3 hours per week on workflows that used to require manual intervention every shift.
If you want to see how Stationwise handles the specifics above for your department, book a demo.
