← All case studies
RapidLogic in-house project
TSL / Municipal services · Mobile app (PWA)

The driver app, a dispatcher panel that fits in a pocket

The dispatcher panel for a septic service company took weeks to build, because it required learning somebody else’s trade first. The driver app took around 30 hours, because it is not a separate product but a slice of the same system: the same data, narrower permissions and an interface rewritten for a thumb. The driver gets the working day on a phone, navigation to the customer’s gate and a place to settle the cash he collected.

Tidly driver app on two phones: the dashboard with today's job list and the status and payment screen
30 h
Of work on the app
0
App stores between us and the driver
1 truck
Data scope visible to a driver
1 system
Shared with the panel, no separate database

A third window onto the same data

Tidly is an in-house RapidLogic project, a two-sided platform connecting homeowners with waste collection companies. We described the customer side in the Waste collection marketplace case study and the back office side in the Dispatcher panel for septic companies. This entry covers the third window onto the same set of data, the one that travels in the truck cab.

The driver app is not a separate system. It is a slice of the dispatcher panel: the same jobs, the same statuses and the same price lists, shown in a vertical layout and trimmed to the scope a driver needs to complete a run. Price matrices, company settlements and customer data belonging to other trucks are simply not there, because none of it is required to drive a route.

That is where the whole argument of this case study comes from. A second app in a system costs a fraction of the first one, provided the data architecture was designed once and designed properly. The panel required weeks of market analysis and interviews with carriers. The driver app closed in roughly thirty hours.

A working day written on a note on the dashboard

Very few companies in this trade run it properly. Our interviews put it somewhere between one and five percent of the market. Such a company prepares a solid list in a spreadsheet and sends it to drivers over a messenger. The rest take jobs by phone all day long, write them on paper notes and hand those notes to drivers in the morning.

The trouble starts after eight in the morning, because the working day never stays the way it looked on the note. Somebody cancels a pickup, somebody else asks for an urgent visit the same day. The owner or the dispatcher takes that call, then rings the driver and asks him to swing by a particular address. The driver adds it to his own note, at the wheel, mid route.

How it works without the app

  • A paper job list handed out in the morning, accurate until the first change
  • Every change during the day means a phone call from the dispatcher
  • Notes about a dog on the property or a difficult approach stay in the conversation
  • Cash collected without a record, settled only in the evening at the office
  • A job taken by the driver lands in a notebook and waits to be retyped

How it works in the Tidly app

  • Today’s list on the phone, updated the moment something changes
  • A new job arrives as a notification, with no phone call involved
  • Customer notes travel with the job and are visible before arrival
  • Collected cash is logged against the job, so the till adds up in the evening
  • A job phoned in to the driver enters the system in three taps

Six things a driver does from the phone

Designing this view, we started from what a driver actually does, rather than from what the panel is able to display. Six areas were left. Each one is below, together with screens from the working app.

Morning: a working day instead of a paper note

The first screen after logging in is a dashboard with a monthly calendar showing the number of jobs on each day. Below the calendar the driver sets his availability for the day, which the dispatcher panel uses when distributing work. Further down runs the job list with address, status and order source, and every row carries three actions available without opening the job: navigate, edit and view.

Changes during the day no longer require a phone call. When the dispatcher adds a job, the driver gets a notification and the row appears on the list. The job can land close to another order in the same area, because the panel takes into account completion status, availability and the daily run limit of a given truck. We described the zoning mechanics in the dispatcher panel case study.

Driver dashboard in the Tidly app: monthly calendar with job counts, availability switch and today's job list

The daily dashboard: a calendar with job counts, an availability switch and a list carrying navigate, edit and view actions.

Notification list in the Tidly driver app with new jobs and a mark as read action

Notifications replace the call from the dispatcher. Every new job has an entry here, with address and amount.

A job seen from the inside

The detail view gathers everything the driver needs to know before entering the property. At the top the ordered service with tank capacity and any extras, for instance a surcharge for a longer hose. Then whether the pickup is contactless and whether the property has a quick coupling, the notes written by the customer and finally the total to settle.

The section below holds customer details with a phone number that dials or texts in a single tap, plus the billing data. None of it has to travel through the office any more, because it rides along with the job.

Job details in the driver app: service, tank capacity, extras, customer notes and total

The ordered service with surcharges, quick coupling information, customer notes and the total to settle.

Customer and billing details in the Tidly driver app, with call and message actions

Contact and billing details. Calling and texting work in one tap, with no number to copy out.

Navigation to the gate, including for a driver from abroad

This element looks trivial until you look at who actually drives these trucks. Waste collection work is not pleasant, so applicants are scarce and it is easier and cheaper for companies to hire drivers from abroad. Two barriers show up at once: knowledge of local geography and communication, because reaching such a driver means a phone call and an effort to be understood.

In the app every job address carries a map and a button that launches navigation, exactly as in ride hailing apps. Approach notes sit above the map, so information about a dog on the property or an entrance from the back of the plot arrives before the truck does, not after. In counties like Wieliczka, where house numbers follow no obvious order, that is the difference between a run and a search party.

Service address in the Tidly driver app: approach notes, map and a button launching navigation

Approach notes above the map and navigation behind one button. The driver does not have to call and ask for directions.

Cash that adds up in the evening

Cash handling in this trade looks the same as it did thirty years ago. Drivers collect money from customers, give change and carry the takings back to the office. With five, ten or fifteen trucks somebody eventually makes a mistake, and in the evening the till comes up short with no way to trace it to a particular run.

In the app a single job carries a payment method, a payment status and a completion status, and the driver changes all three from the phone. With online payment the status arrives on its own. With cash the driver logs the amount he collected against the job, so in the evening he should hand over exactly what the system shows. The flow of money stops being a matter of trust and memory, because every unit of currency has its own row.

Service status in the Tidly driver app: order source, payment method, payment status and completion status

Payment method, payment status and completion status. The driver changes all three without contacting the office.

A job taken from the cab

Letting drivers create jobs looks like a breach in the division of roles, until you count how these companies really look. Not every one of them has a dispatch desk. Tidly also serves one, two and three person operations, where the customer rings the driver directly because he kept the number from the last pickup.

Without a system such a job lands in a notebook and has to be retyped into a computer in the evening. In the app it takes three taps and a minimum of data, a date and a note, because the screen was designed to be operated in the cab. Price, the invoice flag and the address with map verification wait in the second tab and can be filled in later, at a computer or during a stop between runs.

Creating a job in the Tidly driver app, step one: service date and a note

Step one is the minimum that can be typed in a cab: a date and a note.

Creating a job in the Tidly driver app, step two: price, invoice flag and address with map verification

Step two gets completed later: price, invoice and an address checked on the map.

A correction in the field and a personal archive

A job keeps changing after it is accepted, so the driver can edit it. The customer calls to say there is a dog on the property or that the entrance runs from the field side, and the driver adds that as a note, changes the date or the status. The same change is immediately visible in the office panel, because both apps work on one set of data.

The last screen is a history of the driver’s own jobs with a search box and filters by source, status and date range, plus a switch between list and map. The driver can check when he last visited a given address instead of calling the office to ask.

Editing a job in the Tidly driver app: date, note, status and assigned truck

Editing a job from the field. A note about a dog or an approach stays in the system, not in the driver’s head.

Driver job history in the Tidly app with filters by source, status and date and a list or map switch

A history of the driver’s own jobs with filters and a map view, available without asking the office.

Why a PWA rather than an app from a store

The driver app is a progressive web app, which means it runs in the phone browser while installing and launching like a normal application. The choice followed from the stage of the project. While you are still checking whether an idea will land at all, a native release on two operating systems means a separate project, separate releases and a review process in two stores. We needed this on the same day the panel existed.

As a result the app was built as a natural extension of the web side, at a fraction of the cost of a separate mobile project. Installing it on a driver’s phone comes down to opening a link and choosing add to home screen. From that moment the icon sits next to the other apps, and the company pays nothing for distribution and waits for nobody to approve a release.

A native app was planned for the case where the system caught on and a need appeared, working without coverage for example. Until then it would have been money spent on something nobody had verified yet.

How far the testing went. The app went through hallway testing and installation on devices belonging to family, friends and two professional drivers from the transport trade. There was no production rollout in a septic service company, because the commercial development of Tidly was paused, which we cover in the marketplace case study. We are reporting exactly as much as we checked.

What this app does not have

The scope was trimmed on purpose, down to what a driver needs to complete a run and settle a job. Below are the things such apps sometimes carry and ours does not.

Not built

  • An offline mode, so the app requires a network connection
  • A meter photo and a customer signature on screen
  • An automatic run order calculated by the system
  • Native releases for iOS and Android

Why that way

  • Each of these waits for the moment a paying customer asks for it
  • Route ordering through Google Maps is something we have already built in an earlier catering logistics system
  • The priority was testing the business model, not completing a feature list
  • Adding them today is work measured in days, not months

An app that starts from somebody else’s work

This case study has no market analysis phase of its own, because all of that work happened earlier, on the operations panel. Below is the course of this particular part.

Foundation
The operations panel and the data model
Jobs, statuses, payments, fleets, price lists and permissions designed once, for the dispatch desk. That is why the driver view needed no separate database and no synchronisation.
Step 1
Splitting the permissions
Assigning drivers to trucks and narrowing the view to jobs belonging to their own vehicle. Price lists, company settlements and customer data from other trucks stayed outside the reach of that account.
Step 2
An interface for a thumb
Rewriting the views into a vertical layout: a dashboard with a calendar, actions on the list row, job details in sections and a new job form split into two steps.
Step 3
Installation without a store
Shipping the app as a PWA, meaning a link and add to home screen. No distribution cost, no review process and one release for both operating systems.
Testing
Somebody else’s phones
Hallway testing and installation with family, friends and two professional drivers from the transport trade. There was no production rollout in a septic service company.

What this means for a company with people in the field

We have no results from a rollout at a paying carrier and we are not going to invent any. What we do have is a measured amount of work and a working product, and that is enough to show what a second app costs in a well designed system.

30 h
Of work on the second app
Against weeks of analysis and building for the panel it came from
$0
Cost of distributing it to drivers
A link and add to home screen, with no stores and no review process
3
Taps to accept a job from the cab
The remaining fields get filled in later, during a stop or at a computer
1
Record of a job, shared by office and cab
A change in the field shows up in the panel at once, with nothing retyped

Why this matters to a transport company

Waste collection sounds like a narrow niche, yet the driver app solves a problem that looks identical in every company with people in the field. Somebody receives a task list in the morning, drives to an address he does not know, needs the full picture before stepping onto customer ground, changes a status once the work is done and settles money. Exactly the same thing happens in technical service, in deliveries and in installation work.

The conclusion for an owner is not a feature list, though. If company data lives in one place, every further view onto it costs a fraction of the first one. The office panel took weeks, the driver app thirty hours, because nothing had to be designed from scratch. It works just as ruthlessly in reverse: companies keeping every process in a different tool pay for the same integration several times over.

Today we would build it faster still. The same scope delivered with AI-assisted engineering, which we show in the Fortress and Invoice Automation case studies, takes roughly three times less time and money, and comes without the limits of a no-code platform.

Cash handling in this trade is a story from thirty years ago. Drivers collect the money, give change and carry the takings to the office, and with ten trucks somebody eventually makes a mistake and the till comes up short in the evening. In the app the driver logs the amount against the job, so the till either adds up or you can see straight away which run it went wrong on.

Krzysztof Gromadzki, founder of RapidLogic
Krzysztof Gromadzki Founder of RapidLogic, creator of Tidly

Do your people in the field still run on paper and phone calls?

A task list on a phone, navigation to the customer address, a status change and cash settlement is the scope we built into Tidly in roughly thirty hours. A free digital audit will show what such an app could look like for you and which system it could stand on.

Book a free digital audit
See all case studies