Schedule repair bays against real job time

How it works

flowchart TD
  book["Named bay + duration"] --> fit{"Hours left on that bay?"}
  fit -->|yes| slot["Confirm slot + WhatsApp"]
  fit -->|no| later["Offer a later slot"]
  walk["Walk-in"] --> leftover["Leftover duration only"]
  leftover --> slot

1. Each booking asks for a bay and a service duration instead of a vague “before noon” slot.
2. Walk-ins consume leftover capacity. No-shows are tracked so Monday does not silently overflow.
3. The floor view shows job card, technician, current task, and time on floor per bay.
4. Calendar sync keeps the owner’s phone aligned with the same slots the advisor sees.

Key facts

• 4 bays, configurable daily capacity (12 weekday, 8 Saturday).
• Duration-aware slots: general service ~2 hours, oil change ~45 minutes.
• WhatsApp reminder the day before and the morning of the visit.
• No-show tracking and walk-in aware booking.

Overbooking is usually not greed. It is a whiteboard that cannot subtract. If three 2-hour services and four 45-minute oil changes are all written as “morning”, the shop has promised more bay-hours than exist. Tyming Chain refuses that lie at booking time.

The same clock feeds the owner view: occupancy, bikes waiting, and jobs that have been on the lift too long. That is the difference between a list of names and a schedule. Read the playbook: how to stop overbooking repair bays.

Service advisors still take walk-ins. The rule is that a walk-in consumes leftover duration on a free bay, it does not insert a phantom eighth job into a four-bay morning. If a corporate fleet drops six scooters, the booker sees the remaining bay-hours before promising evening delivery. That conversation is the product: honest capacity, then a WhatsApp confirmation the customer can screenshot.