Public Safety Staffing and Overtime Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the callback engine get scoped as a sorted list?

Because in the first requirements meeting it genuinely sounds like one. Order by seniority within rank, skip anyone on duty or on approved leave, offer in order. Ten departments will each describe theirs that way and each will insist it is obvious. The complexity appears at the third question, not the first.

Some departments order by lowest accumulated overtime hours in a rolling window that resets annually. Some maintain separate orders per specialty, so a hazardous materials vacancy pulls from a different list than an engine seat. Some let members sign up for specific days in advance, which pre empts the list entirely. Some require a defined number of contact attempts before moving on, and departments disagree about whether a voicemail counts as a pass or as no contact. Then the conditional clauses arrive: an involuntary holdover counted as an overtime hour for equalization but not for callback order.

The moment a rule depends on a previous event, a sort order cannot express it and a human returns to the loop. The fix is to model the callback policy as an explicit, versioned rule set with the contract clause cited next to each rule, then have the engine produce an ordered candidate list that records why each member was ranked where they were, every contact attempt with a timestamp and outcome, and the acceptance. When the grievance arrives six weeks later you produce the derivation for that vacancy on that night. Most grievances end there.

What goes wrong when roster and accrued overtime history are migrated?

Equalization is a running total, which means cutover is not a clean line. If accumulated overtime hours restart at zero on go live day, the members who have been carrying the most hours are suddenly at the front of the list and the members who have been getting the calls are at the back. That is a visible unfairness on the first night and it will produce a grievance about the software itself, which is a difficult conversation to have in month one.

The source data is usually a binder, a spreadsheet maintained by the staffing officer, and a payroll export that counts hours differently from the way the contract counts them for equalization purposes. Those three will not agree. Seniority dates carry their own problems: a member who transferred from another department, a break in service, a promotion date that governs rank order separately from hire date, and the handful of individually negotiated positions every department has.

The fix is to load the ledger as the staffing officer maintains it rather than as payroll reports it, reconcile the two before cutover and document every difference, then have the union representative and the staffing officer jointly sign off the opening balances. Treat that signed opening position as a record in the system, not as an email. Seniority should be stored as dated events, hire, promotion, transfer, break in service, so rank order can be recomputed rather than typed. And keep the migrated ledger visibly distinguishable from hours the system itself accrued, because the first serious dispute will be about a balance that predates the software.

Why do payroll and dispatch integrations break after launch?

Payroll is the fiddliest part of this category and it is where the build most often goes wrong after go live. Scheduling logic and pay calculation are different problems that must reconcile. The system knows a member worked a callback. Payroll needs to know which pay code that maps to, at what multiplier, against the work period the department declared under the partial exemption in section 7(k) of the Fair Labor Standards Act. Municipal payroll systems are old and every pay code mapping is a negotiation with finance as much as a technical task.

It breaks afterwards for ordinary reasons. Finance adds a pay code for a grant funded assignment and nobody tells the staffing system. A pay period boundary falls inside a shift and the two systems split the hours differently. Each produces a small discrepancy that a payroll clerk fixes by hand, and manual fixes hide the fault until the totals diverge enough to be noticed.

Computer aided dispatch integration fails more quietly. It exists to keep on duty status accurate without anybody keying it, and when the feed stops, stale status looks exactly like current status. The fix for both is the same: validate inbound and outbound data against a strict schema with a blocking failure rather than a tolerant import, monitor freshness so silence raises an alert the same day, and reconcile scheduled hours against paid hours on a defined cycle so a mapping error surfaces in days rather than at year end.

What happens when trades, paybacks and holdover are not covered?

Members trade shifts. Under most agreements a trade creates a payback obligation with a time limit, which means the department carries a liability until it is worked. In almost every department we have looked at, that ledger lives in a station notebook. The problem surfaces when a member retires, transfers or separates with an unpaid balance, or when the trade partner leaves first, and there is no agreed record of what was owed.

Mandatory holdover has the same shape and higher stakes. There is an order, usually inverse seniority. There are limits on consecutive hours that exist for real safety reasons. There is a record requirement, and an involuntary holdover is the kind of event that gets challenged. Departments that run holdover from a supervisor's judgement are relying on that supervisor remembering who was held last time and who is approaching an hours limit at the end of a long shift, which is precisely the moment human recall is worst.

The fix is to treat both as ledgers with rules, which is what software is for and what a binder is not. Trades carry a payback obligation with a due date and an escalation before it expires. Holdover carries its own order, its own hours limits enforced at selection rather than discovered afterwards, and the same derivation record as a callback. Neither is glamorous. Both remove a recurring category of dispute entirely, and holdover in particular removes a safety exposure that nobody enjoys explaining after an incident.

Should you build custom or configure what you already own?

If you run a smaller combination or volunteer department with a simple agreement and a straightforward availability model, buy Vector Scheduling and put the money into apparatus. It handles that profile well and cheaply, and a custom build at that size is a project a council will rightly question. UKG TeleStaff has long fire service history and genuinely good contact automation, so if your rules fit its configuration and your staffing officer is not maintaining a parallel spreadsheet, keep it. InTime is worth including in a comparison on the police side.

The reliable tell that configuration has failed is simple and you already know the answer: if your staffing officer keeps the real list in a spreadsheet alongside the product, the tool did not fit. Build when two or more of these are true. Your callback order is conditional on prior events. You maintain separate orders by specialty or by station. 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. There is a middle path worth pricing: keep the packaged product for rostering and leave, and build only the callback and holdover rule engine that your agreement actually specifies.

How do hidden costs get into the quote?

A focused first release covering the roster and shift cycles, minimum staffing by station, apparatus and seat, the callback engine encoded from your agreement, contact logging and the audit trail runs $70,000 to $140,000 over 10 to 16 weeks in our delivery experience. A full platform adding trades and paybacks, leave and accruals, certification currency, holdover, payroll export and a member mobile application runs $170,000 to $380,000 over 6 to 11 months. The gap between those numbers and a larger invoice comes from a short list.

• Bargaining unit count. A combined fire and police build is two rule engines rather than one, and they will not share a rule model no matter how similar the clauses look on paper.
• Discovery. Reading the agreement clause by clause with the staffing officer and a union representative in the same room takes two to four weeks. It is the most important part of the project and it is not a formality that can be compressed.
• Payroll integration, where each pay code mapping is a conversation with finance and the work period declaration under section 7(k) has to be reflected correctly in the export.
• Automated outbound calling, if you want the system dialling rather than presenting an ordered list to a supervisor. That is telephony work with its own failure modes and its own recurring cost.

What separates a build that works from one that fails here?

Ask a prospective developer 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. Arbitration looks backwards, and a system that overwrites its own rules destroys the evidence you built it to produce.

Ask them to read one clause of your agreement in the meeting and restate it as a rule. This is fast and unforgiving. Developers who have built for shift operations immediately start asking edge case questions: 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 section 7(k) work period and how overtime is calculated against it, because the payroll export is where this build most often goes wrong.

Sequence 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, and shipping it alone gives the battalion chief something usable on the first night rather than a pilot.

Settle code ownership in writing before kickoff. A municipality should own the repository, the hosting accounts and the right to procure another vendor to continue. At Digital Heroes the client owns the code from the first commit. This system will outlive the current administration, and any vendor lock accepted now becomes a sole source justification somebody has to defend to a council in three years.