Skip to Main Content
D-Tools Cloud Ideas Portal

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

Categories Project Management
Created by Dave Kirn
Created on Aug 5, 2026

Service scheduling forces a time-based day when many shops plan by call count

The need

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.

Why this matters

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.

Possible directions

Exploratory, not commitments.

  • Let an organization define how many service slots exist in a day, independently of operating hours.
  • Allow each slot to be labeled and optionally time-bounded, so a day can read Call 1 through Call 4 rather than a series of clock ranges.
  • Order the service calendar by slot sequence rather than start time when an organization opts into this model.
  • Keep the current time-based behavior as the default, so nothing changes for organizations that schedule by the clock.

Open questions

  • Should slot templates vary by day of week, by technician, or by service type?
  • How should a numbered-slot day appear to customers who are told an arrival window?
  • What happens when a call runs long and pushes the rest of the sequence?
  • Do organizations want a mix, where some technicians work numbered slots and others work timed appointments?
  • How should this interact with the arrival-window duration settings that already exist?
  • Attach files