Separate booking from dispatch

Before proposing an interface, write down what the customer is allowed to request and what the dispatcher is authorized to confirm. A customer may choose a preferred window; the service may still need to check a crew, zone, travel, equipment, or existing commitment. If the business cannot name who owns that decision, a new board will only display the ambiguity faster.

The accompanying dispatch decision record uses a representative two-crew scenario. It keeps three paths distinct: assisted dispatch, a configured scheduling path, and a narrow custom layer. The record has no vendor score because this is a build/no-build question, not a platform ranking.

Apply hard stops before convenience scores

Stop at do not build when any of these is true:

  • No person owns the authoritative dispatch decision.
  • A wrong assignment, cancellation, or staff absence has no recovery owner.
  • The team has not documented data classes, access, retention, and an owner for location, payment, identity, or other sensitive data.
  • The custom layer becomes the system of record without an operating and support owner.

An attractive calendar cannot average away any of these missing boundaries.

Run the smallest credible trial

First, have a coordinator record one bounded request, zone, assigned crew, change, and final outcome in the current process. Then, if an existing tool is in scope, run one approved test window and retain what it actually displays about conflict, cancellation, and correction. Do not infer behavior from a sales page or a generic booking link.

No approved assisted or configured trial means investigate, not build. Consider a narrow build only if both paths fail the same necessary, stable requirement and the service owner accepts the support and recovery burden. Otherwise, clarify the existing workflow and measure real exceptions.

Does a customer booking link solve dispatch?

Not by itself. Treat it as an entry route; inspect the linked system for an authoritative schedule, allocation decision, change procedure, and recovery owner.

Should the board include live crew location?

That is a separate data and trust decision. Do not add it because it looks useful; define purpose, access, retention, owner, and recovery requirements with the relevant responsible people first.