Tracking Time and Downtime
Live work timers and downtime windows on a work request.
Instead of entering hours after the fact on a response, workers can track time live with a timer — and separately, a request can record how long the affected equipment was out of service.
Work timers
If your user type includes work tracking, a request offers Start Work and Stop Work. Starting opens a timer; stopping records the elapsed time as worker time on the request, and with the worker's labor rate it becomes labor cost — the same result as logging hours manually, minus the guesswork.
A few rules keep timers honest:
- You can have only one timer running on a given request, and running timers on several requests at once requires a user type that allows working multiple requests simultaneously.
- With the right permission, you can also start and stop work for other workers — a lead checking a crew in and out of a job records everyone's time in one step.
- Several people can have timers running on the same request at the same time; each worker's time is recorded separately.
Downtime
Separately from who's working, a request can record that something was down. Start Downtime stamps the moment the equipment stopped working; End Downtime closes the window. The downtime automatically attaches to the equipment assigned to the request, which is what feeds the uptime history described in Meters & Downtime Tracking. FMX checks for conflicts, so you can't record overlapping downtime windows for the same equipment.
Downtime entries can be edited afterward by users with permission — useful when the boiler actually failed Friday night but nobody logged it until Monday. Depending on your organization's configuration, the downtime forms can also carry custom fields (a "Cause" drop-down, for example).
Starting and ending downtime is its own permission, distinct from work timers, and it's only relevant for equipment types your organization tracks downtime on.
A worked example
A chiller goes out Sunday evening. Monday at 7:00, the lead technician opens the request, selects Start Downtime, and backdates the start to Sunday 6 pm per the building's temperature logs. He then selects Start Work for himself and his apprentice. At 10:30 the chiller is running: End Downtime, then Stop Work for both. The request now shows 3.5 hours of labor for each of two workers — costed at their rates — and the chiller's record shows a 16.5-hour downtime window, with nobody reconstructing times from memory.