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
Service scheduling in D-Tools Cloud is built around clock time. You define operating hours, and the day is divided into fixed-length blocks that service calls drop into. That works well if your dispatchers think in appointment times.
Some service organizations do not plan that way. They plan by how many calls a technician can complete in a day. Their day is "Call 1, Call 2, Call 3, Call 4," and the sequence matters more than the clock. A call might be scheduled for a customer window, but internally the crew works a numbered list, and how many slots exist per day is a deliberate capacity decision that varies by team, season, or job type.
For those shops, the current model creates friction. Slot lengths that do not match how long their work actually takes mean either padding the calendar with blocks nobody uses or fighting the schedule to fit reality. The calendar orders and labels the day by time when what the team cares about is call order.
Capacity planning for a service business is often expressed in calls per day per technician, not hours. When the scheduling tool cannot express that unit, dispatchers keep the real plan somewhere else, usually a whiteboard or a spreadsheet, and the calendar becomes a record of what happened rather than the tool that drives the day.
Exploratory, not commitments.