Менеджер і майстер: чому це два застосунки, а не один кабінет

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

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

Один кабінет на всіх — найдорожча економія

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

Наслідок передбачуваний. Майстер не користується системою, а дзвонить менеджеру; менеджер заводить за нього статуси руками; за місяць у системі видно не роботу, а те, що менеджер устиг переписати. Облік є, довіри до нього немає.

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

Що бачить менеджер

Застосунок менеджера зроблений для голови ОСББ, менеджера керівної компанії й забудовника. У ньому:

• усі звернення мешканців з фільтром за статусом — видно повну картину, а не окремі листи;
• призначення відповідального в один дотик, без повернення за компʼютер;
• створення заявки прямо в смартфоні — під час дзвінка або розмови у дворі. Це знімає найгіршу фразу в будинку: «напишіть звернення»;
• чат у межах конкретної заявки — з мешканцем і з майстром, тобто розмова лишається при справі, а не в загальному чаті;
• фотофіксація й оцінка від мешканця після виконання;
• перемикання між кількома ЖК в одному застосунку.

Останній пункт — те, заради чого керівні компанії зазвичай і переходять. Менеджер, який веде пʼять будинків, інакше тримає пʼять чатів, пʼять таблиць і пʼять наборів телефонів.

Що бачить майстер

Застосунок майстра зроблений для персоналу управителів і сервісних служб — і будинку, і котеджного містечка. Список коротший, і це навмисне:

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

Чого в ньому немає — списку всіх мешканців, фінансів, документів будинку й чужих заявок. Не тому, що «не встигли додати», а тому, що майстру це не потрібно, а будинку — не безпечно.

Підвал, у якому немає інтернету

Це та деталь, через яку системи зазвичай і провалюються в реальній роботі.

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

Фото й оцінка: петля, яка закриває заявку

Фотофіксація працює у два боки, і саме тому вона варта більше, ніж здається.

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

Будинок, у якому заявки закриваються без фото й без оцінки, має журнал. Будинок, у якому вони є, має доказ.

А якщо «менеджер» — це голова ОСББ

У більшості ОСББ немає ні диспетчера, ні штату: голова приймає заявку, він же дзвонить сантехніку, він же перевіряє результат. Здається, що розділяти ролі тут нема між ким.

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

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

Що видно керівнику через місяць

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

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

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

Що кажуть майстри в перший тиждень

Заперечення однакові майже скрізь, і жодне з них не технічне.

«Мені простіше, коли дзвонять». Правда, доки заявок три на день. На десяти починається інше: дзвінок застає в підвалі, адресу записують на руці, а ввечері ніхто не памʼятає, у якій квартирі що робили.

«Я не фотографуватиму кожен кран». Фото потрібне не для контролю, а для майстра: саме воно закриває суперечку «ви нічого не зробили» без його присутності.

«У підвалі немає інтернету». Це єдине заперечення, яке мало бути правдою, — і саме на нього є офлайн.

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

Чого ці застосунки не роблять

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

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

Що перевірити на демо

Чотири питання, на які варто побачити відповідь руками, а не на слайді:

• Заведіть заявку в застосунку менеджера під час розмови — скільки це дотиків?
• Відкрийте застосунок майстра в режимі польоту: заявки видно? Зміна збережеться?
• Подивіться, що бачить майстер із чужих заявок і даних мешканців. Має бачити нічого.
• Перемкніться між двома обʼєктами в обох застосунках — без повторного входу.

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