Solution
Research first, the system afterwards
This project did not begin with building, but with learning somebody else’s trade. First we went through the market of software for septic service companies and picked seven leading systems for detailed analysis. From each of them we took the features that actually solve a problem, then redesigned them using our own experience from building a transport management system for meal-prep caterers, where last-mile logistics looks much the same.
With the process design ready, we went to the carriers. We made around ten phone interviews and met in person with one of the most innovative companies in the region, to talk through what works in current systems, what is missing and how it should look. Only after that conversation did we start building.
The process mapped across three lanes before the build: what the customer does, what the driver does without a system and what the app takes over.
The dashboard, or the working day on one screen
The first screen after logging in answers the question every dispatcher asks each morning: what do we have to do today. It shows the jobs for the selected day split into pending and completed, a monthly calendar with the number of jobs on each date and a team availability switch. From the same place you can add an order taken by phone, because the phone does not disappear overnight.
The daily dashboard. All screenshots come from a demonstration account, on sample data.
Route planning: columns, dragging and a map
The heart of the panel is the planning screen. Jobs line up in columns assigned to trucks, next to a column of jobs not yet assigned. Assigning means dragging a job card onto the right vehicle, and the order of stops is set within that same column. A dispatcher who used to lay out sheets of paper for a dozen trucks gets the same picture on screen.
The first column holds jobs with no truck assigned, every column after it belongs to a single vehicle. The switch above the columns opens the same day on the map.
The second view of the same day is a map, where every job carries the colour of its assigned driver. This view exists for one specific situation that happens regularly in this trade: a truck breaks down, or gets stuck in the snow on the way to a property. Its jobs then have to be spread across the remaining vehicles, and looking at the map from above you can see at once who should take what. The same applies to an urgent job dropped in during the day, because you can see which truck is closest and which treatment station it should drive to for the run to pay off.
The pin colour matches the driver. When a truck breaks down, you can see how to spread its jobs across the rest.
Two automations that take work off the dispatcher
The panel does not pretend it can plan everything for a human. Instead it takes over two tasks that repeat in the company every single day.
- Zoning. Trucks are assigned to regions and towns. When an order comes in from a given town, it reaches the right vehicle by itself, with no decision from the dispatcher.
- A daily limit per truck. Each vehicle gets a maximum number of pickups per day, for example eight. Once the limit is used up, that truck’s availability in the zone closes for that day, so a customer cannot order a service there is no way to deliver.
The second automation is more interesting than it looks, because it connects the panel with the marketplace. The availability calendar a customer sees when choosing a company follows directly from the fleet configuration and the limits set by the carrier. The company sets its own working rules, and the platform sells exactly as much as that company can handle.
Working days, required lead time and the daily job limit. This is where the availability shown to customers comes from.
The price matrix, the thing we were told could not be done
The hardest element of the whole panel turned out to be pricing. The price of a pickup depends at the same time on tank size, tank type, meaning whether it is a septic tank or a domestic treatment plant, the town, because that determines the distance to the treatment station, and on any extra services. In our interviews, carriers said plainly that putting this into a system could not be done and that prices would always be agreed in conversation.
Careful research showed, however, that a handful of companies manage it somehow. We gathered their practices, verified in interviews which extra services genuinely raise or lower the value of a job and how location affects it, and out of that the matrix was born. A company fills it in once for its towns, and the system sells its services at exactly those prices.
The town in the row, the tank capacity in the column, all of it kept separately for each municipality and tank type.
On top of the matrix come extra services billed in bands. The most common example is the hose: the standard one reaches 20 metres, and every further ten metres is a separate charge. Thanks to that, a customer whose tank sits far from the road sees the real price of their service before ordering, while the driver does not have to negotiate a surcharge on site.
Orders from two worlds in a single list
Jobs reach a septic company two ways: from the platform and the classic way, by phone. The panel treats both the same, marking only the source. The list can be filtered by source, completion status, payment status and date range, while the search box finds a job by customer or address.
Jobs from the platform and orders taken by phone in one place, with the source marked.
The detail view gathers everything the driver and the accountant need from a single job: the ordered service with its extras, customer and invoicing details, the address with a map, the payment method and status, and the notes written by the customer. Those notes solve the problem carriers raised most often, because information about a dog on the property or a difficult approach finally travels with the job instead of getting lost in a phone call from last week.
The full record of one job, including the customer’s notes about access. The data on the screenshot is sample data.
Municipalities and permits, or compliance built into the process
This part of the panel looks unremarkable, yet for both sides of the market it is one of the more important ones. A homeowner must hold a contract with a company that has a permit to collect waste in their municipality, and the absence of such a contract carries heavy fines. So the company adds its serviced municipalities together with permit documentation in the panel, which gives the platform operator proof that the carrier operates legally.
The benefit on the customer side is simpler still. Since the platform knows the carrier’s permits and the customer’s municipality, the required contract can be concluded automatically at the moment of ordering. The homeowner stops worrying about it, because the document is created in the background. Watching the deadlines, meaning alerts about permits nearing expiry, was on the plan as well.
Serviced municipalities with their permits. This is how the platform knows who may legally collect waste at a given address.
Fleet, drivers and the scope of access
The last configuration layer describes the company’s resources. Trucks have their capacity, drivers are assigned to vehicles, and each of them sees only the delivery list of their own truck. A driver has no access to price lists, settlements or other customers’ data, because none of that is needed to complete a run.
Out of that separation of permissions grew the mobile driver app, a slice of the panel shaped for fieldwork. We cover it in a separate case study, because it follows completely different rules than work at a desk.
The fleet is the foundation of zoning, daily limits and driver permissions.
What was built, and what stayed on the drawing board. The panel works within the scope described above. We deliberately did not build four things that were planned: reports for municipalities and treatment stations, an integration with an accounting package, a KSeF integration and a digital vehicle file with service reminders. Automatic ordering of stops along a route also stayed on the list, even though we had a working pattern from the catering system. All of these were simpler than what already existed, so they waited for the moment the platform would win its first paying carriers. That moment never came, which we describe honestly in the marketplace case study.
