Solution
Five things the customer handles alone
We designed the system around the questions customers ask over the phone. Each of them got its own place on the screen, which is what stops it from being a reason to call.
How long until the next pickup
The first screen after signing in answers the question that matters most in this service. A bar shows how full the tank is, below it sits the date of the last reading and the predicted moment the tank fills up. Further down are the three most recent orders with amounts and statuses, and at the bottom an order button that takes the customer to the marketplace.
This is where the point of the whole platform becomes visible. The tank owner stops guessing when to call, because the information is in front of them.
The dashboard answers the question customers used to reach for the phone with: how long until the next pickup.
The customer chooses where the number on the dashboard comes from: the sensor in the tank or the pickup history.
Two ways to the same number
Tank level can be shown in two ways and we built both. The real sensor is an integration with a physical device in the tank that exposes an open API. The platform reads the liquid level from it, so the bar on the dashboard shows the actual state. That part was built and tested on a working tank.
The virtual sensor answers the fact that most people have no device in their tank and have no intention of buying one. The algorithm takes the average number of days between previous emptyings, checks how many days have passed since the last pickup, divides one by the other and turns the result into a percentage. The longer a customer uses the platform, the more accurate that estimate becomes, because the history grows.
The second option is commercially more interesting than the first. Value that normally requires buying hardware is produced here from data the system already holds.
An order seen from the inside
The order view gathers everything that used to live in the memory of both sides after a phone call. At the top the ordered service with tank capacity, extras and the total. Below it the customer and billing details, the service address with approach notes, the details of the company that took the job, and the service status with the payment method and payment state.
Personal details, billing data, address and tank specifics are entered once, in settings. With every following order the system fills them in itself, which removes both the retyping and the company’s questions about things already covered during the previous pickup.
One order in full: service, billing details, address with notes, company, plus payment and completion status.
A history that replaces the ring binder
The list of all orders has filters by date range and status, a search box and a result counter. Every row carries the service, the company, the order date, the delivery date, the amount and the status. This is exactly the set of information that previously had to be reconstructed from receipts in a binder.
One more thing was meant to stand here: an export of the pickup list to a spreadsheet or a PDF, useful during a municipal inspection. That feature was never built, which we cover below.
History with filters and a search box. The same view works on a phone, in a vertical layout.
Settings that show where the project stops
The settings screen is the most candid part of this entry, because it says on its own where the working part ends. The active items are user details, billing details, address and the liquid sensor. Below them sit three greyed out: automatic pickup, notifications and other settings.
That is what a project stopped on purpose looks like, rather than one abandoned. The foundation those three items were meant to stand on is ready, while the move itself waited for a signal that the product would catch on.
Three greyed out items are the list of things we did not build, stated by the interface itself.
