We actually read these.
Ideas submitted here go to the product team, not into a void. Add yours, vote on others, and comment on what matters to your business.
Talk to our Product Managers live: every other Monday, 1:00–2:00 PM ET → https://www.d-tools.com/cloud-product-office-hours
The current scheduling experience treats service calls as a side-effect of project scheduling — useful for the integrator who runs service as a small fraction of the business, unworkable for shops where service is the operating model. Service-heavy users (security integrators, service-only shops, larger AV firms with dedicated service teams) need a dispatch surface built around how service work actually happens day-to-day: geographic awareness, routing, real-time technician visibility, and a UX shaped to a dispatcher's workflow rather than a project manager's Gantt chart.
Geographic visibility on the schedule — service calls plotted on a map alongside the calendar list view, so dispatchers can see where work is and route technicians efficiently when calls cluster in a region.
Routing optimization — when scheduling a sequence of calls for a technician, surface the suggested order based on drive time and live traffic data.
Real-time technician visibility — a "where is everyone" view that shows current location and active call status, so when an emergency comes in the dispatcher can see who is closest and available without a phone tree.
Quality tracking — first-call resolution rate, callback rate per technician, average time to resolve, broken out by call type (warranty vs. customer-pay) and reportable per technician and per shop.
Dispatcher-first UX — the screen layout matches how a dispatcher actually thinks (queue → assign → track → close) rather than how a PM builds a project schedule. Bulk re-assignment, drag-and-drop between techs, and a triage queue for unscheduled calls are first-class.
Customer-facing windows — automated "tech is on the way" notifications with live ETA, and post-visit follow-up triggers.
Integrations — GPS tracking from a vehicle telematics or mobile-app source so the location data is real, not the technician's last manual update.
This is a strategic redesign rather than a tactical scheduling tweak. The existing scheduling work focuses on calendar consistency and event-drawer UX — good improvements, but they don't change the operating model. A real dispatch surface is what unlocks service-heavy verticals (security integrators, service-only shops, MDU) where service is the business. It's also a competitive parity item against established field-service platforms like ServiceTitan and Jobber that integrators already evaluate when their service operation outgrows the current tooling. The data the platform already collects — call records, technician assignments, completion times — is most of what's needed; the missing piece is the dispatch surface itself and the geographic / real-time layer on top.
What does dispatch look like in your shop? What do you do today that the platform forces into a workaround? Drop a comment with your scenario — the more concrete examples we collect, the better we can shape this into something that fits real service operations.
