At this scale, a list of individual problems on the home screen is noise: there is always something offline somewhere. The people running the fleet first need the big picture: how many devices there are, where they are concentrated, how many are online or in service, and which regions and partners carry the load.

So the overview starts from a real map. Device concentrations by area, open alerts on top of them, and a list of regions next to it. Selecting a region opens its partners right in place, which is the first step of the path from global to particular.

Devices in a region are maintained by independent service partners, so the partner is the natural middle level of the hierarchy. For each partner the operator sees how many devices and customer sites they serve, how healthy that part of the fleet is, and how loaded the partner is this week.

This is where decisions are made: whether a partner can take more devices, whether visits need to move, or whether a region needs another partner. From here, one click opens exactly this partner's devices.

The device list is where the fleet is actually managed, so filtering has to be precise. Connection, state, filter life, model, site type, and firmware are always visible with live counts, so the operator sees the shape of the selection before opening it. The scope from the previous level, like the partner, stays as a removable chip.

I combined grouped search by device ID and MAC address with filters, live counts, and configurable columns. I also added a plain-language query that turned into the same visible filters, so operators could always see how the result was built. After selecting devices, they could change settings, create a service task, or plan a route in bulk.

The device opens in a side panel over the list, so an operator can go through several devices in a row. Tabs follow the questions people actually ask: is it maintained, how is it used, how is it set up, what is happening right now, and what happened before.

Filter changes used to follow the calendar. But a device in a busy office and one in a quiet school use very different volumes. Forecasting by the litres that actually passed through the filter makes maintenance earlier where it matters and saves visits where it doesn't. The same telemetry reveals slow problems, like hot water cooling down over two weeks, before they become a breakdown.

Cooling, energy-saving schedules, and portion presets can be changed remotely, for one device or a whole group. A mistake here affects real kitchens, so the flow is built around confidence. Breadcrumbs and steps show where the operator came from and what is left; the selection stays visible and editable; the review shows exactly what changes, what happens to offline devices, and how to roll back.

Every change, whether made by an operator, a service partner, or the user in the mobile app, is written to the device history as “was → became”, with the author and time. When something behaves strangely, the first question is always “what changed?”, and the answer is one tab away.

Stock, models, and assignment were separate sections, but for the team they were one process. The device is scanned in the warehouse, assigned to a customer with a service partner and maintenance plan, installed, and only then becomes part of the active fleet.

Seeing the whole pipeline exposes the gaps between stages: devices that were assigned but never came online, stock that isn't moving, returns waiting for a decision. These are exactly the places where the operational process loses devices.

Maintenance was handled by independent service partners. I designed bulk reassignment of devices and connected the full service loop: a forecast became a task, the task went to a partner, the partner confirmed the visit, and the device data confirmed the result.

I also designed the notification system. The key decision was to notify roles about decisions they own, not about every event.

The same system extends to the people who use the water every day. The customer app shows the state of their own devices and lets them act without calling support: see when the filter needs changing, order a replacement or book a visit, and adjust settings within the limits set by the manufacturer.

It uses the same data model as the admin platform, so every change made in the app appears in the device history, and every visit planned by a partner is visible to the customer.