У такому масштабі список окремих проблем на головному екрані перетворюється на шум, бо десь завжди щось офлайн. Людям, які керують парком, спершу потрібна загальна картина: скільки всього пристроїв, де вони сконцентровані, скільки онлайн чи на обслуговуванні, і які регіони та партнери несуть навантаження.

Тому я почав огляд зі справжньої карти. На ній видно концентрацію пристроїв за зонами й відкриті сповіщення, а поруч розташований список регіонів. Вибір регіону одразу відкриває його партнерів і веде від загальної картини до конкретних пристроїв.

Пристрої в регіоні обслуговують незалежні сервісні партнери, тому партнер став середнім рівнем ієрархії. Для кожного партнера оператор бачить кількість пристроїв і клієнтських локацій, стан цієї частини парку та завантаження на поточний тиждень.

Тут ухвалюються рішення: чи може партнер узяти більше пристроїв, чи треба перенести візити, чи потрібен регіону ще один партнер. Звідси один клік відкриває саме пристрої цього партнера.

Саме у списку пристроїв оператори керували парком, тому фільтрація мала бути точною. Зв’язок, стан, ресурс фільтра, модель, тип локації й прошивка завжди були на виду разом із живими лічильниками. Оператор бачив майбутню вибірку ще до її відкриття, а контекст із попереднього рівня, наприклад партнер, залишався окремим чипом.

Я поєднав пошук за ID пристрою та MAC-адресою з фільтрами, живими лічильниками й налаштовуваними колонками. Також додав запит звичайними словами, який перетворювався на ті самі видимі фільтри. Після вибору пристроїв оператор міг масово змінити налаштування, створити сервісне завдання чи спланувати маршрут.

Пристрій відкривається в бічній панелі поверх списку, тож оператор може переглянути кілька пристроїв поспіль. Вкладки відповідають питанням, які люди справді ставлять: чи він обслуговується, як ним користуються, як він налаштований, що відбувається зараз і що було раніше.

Раніше заміна фільтра йшла за календарем. Але пристрій у завантаженому офісі й у тихій школі пропускають зовсім різні об’єми. Прогноз за фактичними літрами робить обслуговування раніше там, де це важливо, і економить візити там, де ні. Та сама телеметрія показує повільні проблеми, як-от гаряча вода, що остигає протягом двох тижнів, ще до поломки.

Охолодження, розклад енергозбереження й пресети порцій можна змінити віддалено, для одного пристрою чи цілої групи. Помилка тут впливає на реальні кухні, тому сценарій побудований довкола впевненості. «Хлібні крихти» й кроки показують, звідки оператор прийшов і що лишилося; вибірка завжди на виду й редагується; перевірка показує, що саме зміниться, що буде з пристроями офлайн і як відкотити зміни.

Кожна зміна від оператора, сервісного партнера чи користувача мобільного застосунку записується в історію пристрою як «було → стало» з автором і часом. Коли щось поводиться дивно, перше питання завжди «що змінилося?». Відповідь можна знайти в сусідній вкладці.

Склад, моделі й призначення були окремими розділами, але для команди це був один процес. Пристрій сканують на складі, призначають клієнту разом із сервісним партнером і планом обслуговування, встановлюють, і лише тоді він стає частиною активного парку.

Коли видно весь шлях, стають помітні розриви між етапами: пристрої, які призначили, але вони не вийшли на зв’язок, запаси, що не рухаються, повернення, які чекають рішення. Саме тут операційний процес і губить пристрої.

Обслуговування виконували незалежні сервісні партнери. Я спроєктував масове перепризначення пристроїв і зв’язав повний сервісний цикл: прогноз ставав завданням, завдання отримував партнер, партнер підтверджував візит, а дані пристрою підтверджували результат.

Також я спроєктував систему сповіщень. Ми повідомляли кожній ролі про рішення в її зоні відповідальності, а не про кожну подію в системі.

Та сама система поширюється на людей, які щодня п’ють цю воду. Клієнтський застосунок показує стан їхніх пристроїв і дає діяти без дзвінка в підтримку: побачити, коли міняти фільтр, замовити заміну чи записатися на візит і змінити налаштування в межах, які задав виробник.

Застосунок працює на тій самій моделі даних, що й адмінплатформа, тож кожна зміна в застосунку з’являється в історії пристрою, а кожен візит, запланований партнером, видно клієнту.