A trades appointment has to fit travel, work on site and the skills actually available. A free hour in the calendar supplies only part of that information. AI can structure a request and prepare suitable options. A binding promise still needs a check against the real dispatch plan, required equipment and your company’s operating rules.
The dependencies become obvious in a small team. One technician is nearby but carries the wrong equipment. Another has the right experience but would need to cross the region. The customer sees little of this. They hear an arrival time and arrange their day around it. Your planning must be able to support that promise.
Calculate occupied time, not just repair time
A repair expected to take 40 minutes does not automatically disappear from the schedule after 40 minutes. Travel, access, preparation and documentation also take time. Some assumptions remain uncertain: parking, the state of a component or a second problem discovered only on arrival. Make those assumptions visible before using the duration to offer an appointment.
Illustrative calculation, not a measured AlpenAgent customer result: 25 minutes of travel, 10 minutes of preparation, 40 minutes of work, 10 minutes of documentation and a 15-minute reserve occupy 100 minutes altogether. Check the journey to the following job as well. Omitting that connection can make two individually plausible appointments impossible to deliver together.
| Time component | Include in the plan |
|---|---|
| Travel | Starting point and destination from valid location records, together with the estimate used and when it was checked. |
| Preparation and access | Entry arrangements, contact person, equipment and known site constraints. |
| Work on the request | A duration assumption appropriate to the request type, with its uncertainty identified. |
| Completion and reserve | Documentation, an agreed buffer and the connection to the next assignment. |
The reserve is an operating decision rather than a safety margin invented by the model. Specify how uncertainty is handled for each job type. A new fault on an unfamiliar installation may need different planning from a recurring maintenance visit for which the information is already complete and reliable.
The right person is not simply the nearest person
Maintain job requirements separately from availability. Which skill is required? Is a second person needed? Must somebody authorise particular work? Which parts or equipment need to travel with the technician? Those fields determine eligibility. A language model should not infer a missing qualification from a broad description of somebody’s professional role.
The dispatcher confirms the assignments that are valid for your business. A manageable catalogue of approved job types is more useful than lengthy free-text profiles. If a request cannot be assigned confidently to an approved type, it needs clarification or manual planning. Make that a visible ordinary outcome rather than forcing the software to choose something.
Check shared resources too. Two available employees cannot both use the only test device at the same time when both jobs require it. Parts in the warehouse are not necessarily in the appropriate vehicle. Include those conditions before a customer receives a definite time, or a seemingly efficient plan can create another journey before work even starts.
Obtain travel time from a checkable source
The model should not guess a journey duration from place names. Use an appropriate routing source or confirmed operating values, and state their limitations. Microsoft’s travel-time scheduling documentation illustrates the relevance of location records and working hours. Traffic assumptions depend on the particular calculation method and configuration.
Decide where travel starts: your premises, the preceding customer or another authorised location. Mixing these assumptions produces inconsistent results. When an appointment moves, review the affected connecting journeys. Copying the old travel estimate alongside a new appointment does not establish that the route can still be delivered or that the technician will start in the same place.
Separate customer commitments from internal travel estimates in the wording. “Arrival between 10 and 11” differs from “work starts at 10”. Use only the form of promise your company can support and explain. A map displaying an estimated arrival does not replace an agreement with the customer, especially when preparation or access still needs confirmation.
Collect information that changes the dispatch decision
A location, specific request, reachable contact, access arrangements and desired time window may be sufficient for an initial planning record. Add only information that changes the decision. A customer should not have to describe an entire technical installation when the intended first outcome is a callback by someone qualified to assess the issue.
Keep observations separate from diagnoses. “The heating stays cold” can be a useful customer report. A fault cause generated from that sentence is a different statement. Store what the customer described and leave technical assessment with the person who has the necessary information and competence. That protects both the job classification and the instructions reaching the technician.
For urgent or dangerous situations, your emergency boundary takes precedence. A route-planning system should not treat these reports as ordinary requests competing for free calendar space. The team needs to know which notification requires immediate attention and which response the assistant is authorised to provide.
Keep an offered option distinct from a confirmed job
An available-looking option starts as a proposal. Before it becomes a booking, check resources, travel and the current dispatch state again. Somebody may have changed the same period between the first lookup and confirmation. Tell the customer that a booking is confirmed only when the authorised result has actually been saved in the intended system.
Microsoft’s Schedule Assistant documentation describes finding suitable resources. It establishes features of that product, not a completed AlpenAgent integration. Verify which requirements your chosen system considers and which additional checks remain with your business. The same interface label can hide quite different configuration choices.
Give each request a clear status: information missing, awaiting planning, option offered, confirmed or deliberately declined. Assign an owner to unresolved cases. A well-written appointment suggestion must not vanish among chat messages while colleagues assume that the work has already been booked. Status needs to exist where the dispatch team actually works.
Handle an overrun as its own workflow
Define how a longer preceding job changes the day. Which subsequent visits are affected? Who can change their order? When is the customer informed? What does the new message need to say? Automatic messages should not invent another binding time before the dispatcher has approved the revised sequence and checked its practical consequences.
A callback can be more useful than quickly issuing a second unsupported time. Keep the original promise and the reason for its change visible. A colleague can then take over without collecting the request again or overlooking a condition that has already been communicated. This matters particularly when several people answer customer questions during the day.
A first pilot does not need to optimise an entire day
Choose a defined job type in a limited area. Initially compare proposals with your existing planning rather than replacing it. Review estimated duration, actual work, missing information and manual changes needed. Pay particular attention to cases where a mathematically free period turned out to be unusable because a resource, connection or access condition was missing.
Our appointment-logic guide addresses statuses and exceptions. For AI in a trades business, bring location, resource and journey rules too. Those details establish what can be captured automatically and which part of dispatch judgement should remain with the team responsible for carrying out the work.
FAQ
Can the assistant estimate travel time itself?
It should use an appropriate source or confirmed company values. A plausible number generated by a language model is not a verified journey estimate.
Must every appointment be confirmed automatically?
No. Missing information or uncertain capacity can lead to a prepared option with an assigned person responsible for reviewing it.
What about work outside our service area?
Define the area and exceptions in advance. Such a request needs an explicit review path rather than an unsupported standard booking promise.