Fire and Police Staffing Software: Why the 4am Callback List Becomes a Grievance

Why staffing software decides your overtime bill and your grievance count

It is 4:10am. A firefighter on the C shift calls in sick. Minimum staffing at that station requires a driver operator and three firefighters, and the shift is now one short. The battalion chief opens a binder, finds the callback list, and starts dialing. The list is ordered by seniority within rank, but only among members who are not already on duty, not on approved leave, not at their maximum consecutive hours, and who hold the certification the vacancy requires. Behind that, the department also owes an equalized distribution of overtime hours, so the person with the fewest accumulated hours should get the offer first, unless the contract says seniority governs on an emergency callback and equalization governs only on a scheduled vacancy. The chief has about eleven minutes before the next call drops.

He gets it wrong. Not badly wrong, just one name out of order. Six weeks later a member files a grievance for a missed overtime opportunity, the remedy is pay at the rate he would have earned, and the department pays twice for one shift. Multiply that across a year and the number is real. Meanwhile the finance director is looking at an overtime line that grew again and asking why, and nobody can answer with data because the answer lives in a binder and a call log written in ballpoint.

The tools that exist are UKG TeleStaff, Vector Scheduling, formerly Aladtec, and InTime. These are not bad products. TeleStaff in particular has been in fire service for a long time and handles contact automation properly. Where they run out of road is the same place in every department: the contract. Callback order rules, overtime equalization windows, mandatory holdover order, trade and payback tracking, the interaction between accrued leave and staffing minimums, and the work period you declared under the FLSA section 7(k) partial exemption are written into a bargained agreement that is unique to your department and gets renegotiated every few years. Configuration screens express the common ninety percent. The grievances all live in the other ten.

Problem one: callback order is a rule set, not a list

Ask ten departments how they order a callback and you will get ten answers, and each will insist theirs is obvious. Some order by seniority within rank. Some by lowest accumulated overtime hours in a rolling window. Some by a hybrid where the window resets annually. Some maintain separate lists per specialty, so a hazmat vacancy pulls from a different order than an engine seat. Some allow a member to sign up for specific days in advance, which pre empts the list entirely. Some require a certain number of contact attempts before moving on, and some count a voicemail as a pass while others count it as no contact.

Packaged tools model a list with sort rules. That works until your agreement contains a clause like passing a member who was already offered an opportunity in the same twenty four hour period, or one that treats an involuntary holdover as an overtime hour for equalization purposes but not for the callback order. The moment the rule is conditional on a previous event, the tool is out and a human is back in the loop.

What a custom build does: express the callback policy as an explicit, versioned rule set with the contract clause referenced next to each rule. Then the engine produces an ordered candidate list, records why each candidate was ranked where they were, records every contact attempt with a timestamp and outcome, and records the acceptance. When the grievance arrives, you produce the derivation for that specific vacancy on that specific night, and most grievances end there. The rules being versioned matters at every contract cycle, because you will need to show what the policy was on the night in question, not what it is today.

Problem two: minimum staffing is per position, per station, per apparatus

Minimum staffing is rarely a headcount. It is a ladder company requiring an officer, a driver operator with a specific certification and two firefighters, plus a medic unit requiring a paramedic rather than an EMT, plus a rule that the battalion cannot drop below a certain number of officers across the district. A vacancy is not a hole in a shift, it is a hole in a specific seat with specific qualifications attached.

Generic workforce scheduling software, including the enterprise suites a city IT department may already own, models shifts and headcount. It does not model an apparatus with seats, and it does not know that moving a member from one station to another to cover a paramedic seat creates a new hole where they came from. Which is why the chief solves it on paper.

What a custom build does: model station, apparatus, seat and qualification as first class objects, then evaluate coverage continuously rather than at the point of scheduling. The system should propose the move plus the backfill together, and it should refuse to show a solution that leaves the district below its officer floor. It should also surface the cost of each option, because a chief choosing between a holdover at time and a half and a callback at a different rate is making a financial decision at 4am with no financial information.

Problem three: the overtime bill has no explanation

The finance director sees a number. The chief sees a staffing reality. Neither can connect them, because nothing in the current process attributes a dollar of overtime to a cause. Was it vacancy from long term injury leave, from vacation approved above the daily leave cap, from training assignments pulling members off line, from unfilled positions the city never funded, or from apparatus staffing minimums that were raised in the last contract?

This is the analysis that changes budget conversations, and no packaged product gives it to you honestly because it does not know your cost model. What a custom build does: tag every overtime hour with a cause code at the moment it is created, since the vacancy already knows why it exists. Then produce overtime by cause, by station, by month, with the counterfactual attached: this many hours were driven by leave approvals above the cap, this many by vacancy against authorised strength. In our experience this report is what gets the next round of hiring funded, because it converts an argument into an exhibit.

Problem four: trades, paybacks and holdover are a ledger nobody keeps

Members trade shifts. Under the agreement, a trade usually creates a payback obligation with a time limit, and the department carries a liability until it is worked. Today that ledger lives in a station notebook. When a member retires or transfers with an unpaid balance, or when a trade partner separates, the department discovers the problem at the worst moment.

Mandatory holdover has the same shape. There is an order, usually inverse seniority, there are limits on consecutive hours, and there is a record requirement. Both of these are ledgers with rules, which is exactly what software is for and exactly what a binder is not.

What this costs and how long it takes

Across the public sector and shift operations work Digital Heroes has delivered, this is the honest shape. A focused first release, meaning roster and shift cycles, minimum staffing by station, apparatus and seat, the callback engine with your contract rules, contact logging, and the audit trail, runs $70,000 to $140,000 and ships in 10 to 16 weeks. That is a system the battalion chief uses on the first night, not a pilot.

A full platform adding trades and paybacks, leave requests and accrual rules, certification and training currency tracking, mandatory holdover, payroll export, and a member mobile app for availability and offers runs $170,000 to $380,000 phased over 6 to 11 months.

What pushes cost up in this category: the number of bargaining units, because a combined fire and police build is two rule engines rather than one. Payroll integration, since municipal payroll systems are old and each pay code mapping is a negotiation with finance as much as an integration. Automated outbound calling, if you want the system dialling rather than presenting an ordered list to a supervisor. Computer aided dispatch integration, if you want on duty status to reflect reality without keying. And the discovery itself, which is not a formality here: reading the agreement with the union representative and the staffing officer in the same room takes two to four weeks and it is the most important part of the project.

What keeps cost down: start with one bargaining unit, one shift cycle and the callback engine only. Trades and leave can wait a quarter. The callback engine is where the grievances and the money are.

Build versus buy, and when buying is the right call

Buy, and do not call us, if you are a smaller combination or volunteer department with a simple contract and a straightforward availability model. Vector Scheduling handles that well and cheaply, and a custom build would be a vanity project a council will rightly question.

Build when two or more of these are true. Your callback order is conditional on prior events, meaning the rule references what happened earlier in the same period. You have separate lists by specialty or by station with different orders. Your grievances over missed overtime opportunities are recurring rather than rare. Your overtime line is large enough that finance asks for a cause breakdown you cannot produce. Or you tried a packaged product and your staffing officer still keeps the real list in a spreadsheet, which is the tell that the configuration did not fit.

How to choose a developer for public safety staffing systems

Ask them how they would handle a contract change mid year. If the answer does not include versioned rules with effective dates and the ability to recompute a past night under the policy that applied then, they will fail your first arbitration.

Ask them to read one clause of your agreement in the sales meeting and restate it as a rule. This is a fast and unforgiving test. Developers who have built for shift operations will immediately start asking about edge cases: what happens if nobody accepts, what happens when the last member on the list is already at maximum consecutive hours, what counts as a contact. Developers who have not will nod.

Ask what they know about the 7(k) work period and how overtime is calculated against it, because the payroll export is where this build most often goes wrong. The scheduling logic and the pay calculation are different problems and they must reconcile.

Ask who owns the code and get it in writing before kickoff. A municipality should own the repository, the hosting accounts and the right to procure another vendor to continue the work. At Digital Heroes the client owns the code from the first commit, and any firm that hedges on that is building a procurement trap you will be explaining to a council in three years.