If you send work to a network of independent workers — pest control, cleaning, repairs, installs — the dispatch desk is probably one person, a group chat and a call log. Every job goes out as a message, every reply gets chased, every payment is taken over the phone, and the state of the day lives in somebody's head. This is the page for the version where the system holds it instead.
WhatsApp is where the workers already are, which is exactly why dispatch ends up there. But a group chat has no state. Nobody can tell from the thread who has taken a job, who has paid, or which of the three people who said "mine" actually got it.
So the dispatcher becomes the state. They confirm by phone, take the payment by phone, tell the others by phone, and do it again for the next job. The ceiling on the business is how many of those loops one person can hold at once.
The failure modes are predictable: double-booked jobs, disputes over who claimed first, payments that never got logged, and a dispatcher who cannot take a day off without the work stopping.
Marmadbir dispatches pest-control jobs to a network of independent exterminators across Israel. It runs in production, in Hebrew, right to left, on the phones the workers already carry — and it handles the payment as well as the message.
Figures are read from the production system, not estimated. Where something has not been measured, this site says so rather than filling the gap. How we count · All case studies →
The same shape, on your channel and your payment provider.
Jobs broadcast to your WhatsApp group and your Telegram workers the moment they are created, each carrying a one-tap link to apply.
Race-safe assignment: the first worker to accept — or to pay, if you take a commission — wins, in a single database transaction, so two people can never both be told the job is theirs.
Payment collection built in: card tokenisation, per-job commission or monthly billing, with Stripe for UK businesses and the same design on other providers where the market demands it.
Invoices and receipts generated automatically, to the rules of your jurisdiction, and kept for as long as you are required to keep them.
An operator console: job board, application review, message templates with a live preview of exactly what workers will receive, and refund and support tools.
No. They arrive from a WhatsApp or Telegram link on their phone and sign in with their phone number. There is no app store, no password to forget and no training beyond the first message. Most workers never see a desktop.
Both, deliberately. One-to-one messages go through the official WhatsApp Business API with approved message templates. Group broadcasts — which the official API does not support — go through a self-hosted bridge. The production build uses each for what it is good at rather than pretending one covers everything.
A database function claims the slot atomically: it marks the winning application, closes the job and rejects every other applicant in one transaction. Two simultaneous claims cannot both succeed. This is enforced in the database, not in the app, so no race in the interface can get round it.
Yes. The production system collects a commission from the worker before the job is released to them, tokenising the card so repeat payments are one tap. For a UK business this is Stripe; the design is provider-agnostic because the original build had to run on two Israeli providers instead.
Only as configuration. Language, text direction and currency are settings; the payment provider is swapped rather than rewritten. A second variant of the same platform already runs Telegram-only with Stripe for a different market, on the same code.
It depends on how many channels, whether you take payment, and which invoicing rules apply to you. You get a fixed price and a delivery date before anything starts.
Tell me how a job reaches your workers today and how they get paid. If a shared inbox and a spreadsheet are genuinely enough for your volume, I will say so on the call.