Every Job Accounted for,
or It Shows Up in Red.
A dispatch platform for transfer operators who were running on group chats and spreadsheets. Bookings in, drivers assigned, customers notified — and anything that slipped through surfaced before it became a missed pickup.
Every booking sits at exactly one stop. The platform watches the gaps between them — a job still at Confirmed two days before pickup is the problem worth catching.
Platform control,
not a spreadsheet with a login.
Built on Filament so the admin behaves like a desktop application — inline editing, live filtering, and no full-page reloads between screens.
Open full size ↗
Transport runs on
WhatsApp and memory.
A transfer operator's day is a group chat. Bookings arrive by message, get written into a spreadsheet, and drivers are assigned by whoever replies first. It works until volume climbs — then a pickup gets missed, and nobody can say when it went wrong or who was supposed to have it.
The failure is never the booking itself. It's the gap between a booking existing and someone being responsible for it. Nothing in a chat thread can tell you that a job three days out still has no driver.
- Bookings in a group chatNo record of who accepted what, or when
- Assignment by replyJobs silently unowned until someone notices
- Manual confirmationsCustomer messages sent by hand, or forgotten
- Margins exposedDrivers seeing the full customer price
- No cross-border viewRinggit and Singapore dollar jobs tracked separately
One system,
three different truths.
Each role sees exactly what it needs and nothing it shouldn't. That separation is the reason this had to be built rather than bought.
Platform administrator
Sees across every tenant — operator performance, revenue by currency, notification delivery health, and the exception queue for the whole network.
- Tenant provisioning and user management
- Cross-operator booking oversight
- Notification log with delivery status
Operator
Works inside their own tenant only. Takes bookings, assigns drivers, sets customer pricing and driver fees — without ever seeing another operator's jobs or numbers.
- Booking intake and lifecycle
- Driver assignment and scheduling
- Customer price and driver fee, set separately
Driver
A deliberately narrow portal. Drivers log in, see the jobs assigned to them, update status as the trip progresses, and check their own earnings.
Drivers see their own fee and never the customer price. Two separate figures on the same booking, with the customer-facing number simply absent from the driver's view — not hidden behind permissions that could be misconfigured later.
A message sent
isn't a message delivered.
Booking confirmations and pickup reminders go out over the WhatsApp Cloud API and email. The platform logs every send and its outcome, then surfaces failures in the same exception queue as unassigned jobs — because a confirmation that silently bounced is the same operational problem as a driver who was never booked.
Delivery health is tracked as its own metric on the dashboard rather than buried in a log nobody opens.
Failures surface in the action queue within the hour, not at the end of the month.
Built to add operators
without touching code.
Application
- Laravel13
- PHP8.4
- Filament5
Data
- MySQL8.4
- TenancyScoped per operator
- CurrencyMYR & SGD
Integrations
- WhatsAppCloud API
- EmailTransactional
- LocaleEN & 中文
Onboarding a new transport operator is a provisioning task, not a development one — their users, bookings, pricing and drivers are scoped to their own tenant from the moment the account exists.
Running an operation
that no software fits?
Dispatch, bookings, field teams, multi-branch reporting — if the process is specific enough that you've built spreadsheets around it, that's usually the point where custom software pays for itself.