The Schedule tab is the operational timeline: each technician is a row, each visit is a block, laid out on a time axis (Day view at hour resolution, Week view at day resolution). It shows what is actually in motion — Travelling, On Site, Paused — plus, with the "Show completed" toggle, what was accomplished.
DispatchDesk does not run timers, does not write worklogs, and does not track devices. It reads the timestamps already in each ticket's status history (the Jira changelog): when the ticket entered your Travelling status, that's the departure; when it entered On Site, that's the arrival; when it hit your Done status, the visit closed. Blocks span this real window — a job worked all morning looks like a job worked all morning. The one figure that is written to Jira is the ticket's estimate (Jira's native Original Estimate field), which sizes planned blocks before work starts.
A paused ticket's block freezes at the pause moment — it stops growing and stops counting as the technician's running job. If the ticket later goes back to the dispatch queue instead of being completed, the work done before the pause stays on that day as an amber ⏸ interrupted visit block: the day's history never develops holes. If work resumes later, that's a new visit and a new block.
Completed and interrupted blocks are dated by the workflow transition that ended them, attributed to the technician who was assigned at that moment — so reassigning a finished ticket for review, closing it days later at the helpdesk, or automation touching old tickets never rewrites a technician's day. Drag any ticket to another time or technician to reschedule and reassign; in-flight tickets (Travelling / On Site) are protected from accidental reassignment — pause first, then move.
If a past day ever looks emptier than the work that was done, Settings → Diagnostics → Completed schedule re-runs the day and explains, per ticket, exactly why it does or doesn't render.