Заявка мешканця: як влаштована диспетчеризація в ОСББ і керівній компанії

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

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

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

Що таке диспетчеризація

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

Диспетчеризація існує в будь-якому будинку — навіть там, де про неї не чули. Питання лише в тому, де вона живе: у голові голови ОСББ, у зошиті на вахті, у трьох чатах або в системі. Перші три варіанти працюють, доки будинок один, людина одна і вона на місці. Щойно зʼявляється другий будинок, друга зміна або відпустка — порядок розсипається.

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

Шлях заявки: шість кроків

Подання

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

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

Що має бути зафіксовано при поданні: хто подав, коли, де саме (квартира, підʼїзд, поверх, спільна зона), що сталося, фото.

Фото тут не прикраса. Воно знімає більшість уточнень: майстер заздалегідь бачить, який кран, яка модель замка, чи потрібні драбина й напарник.

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

Класифікація

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

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

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

Призначення виконавця

Саме тут процес ламається найчастіше. Заявка прийнята, видно її всім — і вона нічия.

Способів призначення три: вручну, коли диспетчер обирає конкретну людину; за зоною чи спеціалізацією; по черзі між вільними. Будь-який працює, якщо виконується одне правило: у кожної заявки є один відповідальний, і він про це знає.

«Хлопці, гляньте хтось» — це не призначення. Це перекладання відповідальності на того, хто першим прочитає, а найчастіше — ні на кого.

Статус

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

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

Закриття

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

Без фото закриття — це слово проти слова. Через місяць, коли те саме потече вдруге, ніхто не доведе, чи робили ремонт і що саме робили.

Оцінка

Останній крок пропускають найчастіше, а він найдешевший. Мешканець ставить оцінку після виконання.

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

Хто за що відповідає

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

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

В ОСББ

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

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

У керівній компанії

Тут ролі розділені, зате зʼявляється те, чого немає в окремому ОСББ, — кілька обʼєктів. Один майстер обслуговує три комплекси, диспетчер бачить усі одразу, а звітувати треба окремо по кожному.

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

Аварійна заявка

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

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

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

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

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

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

Числа, за якими видно роботу

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

• Кількість звернень за місяць. База, без якої решта не читається. Зростання кількості — не завжди погано: часто це означає, що люди нарешті почали писати замість того щоб мовчати.
• Час до першої реакції. Від подання до моменту, коли в заявки зʼявився виконавець. Саме цей час відчуває мешканець, і саме його найлегше скоротити.
• Час до закриття. Від подання до «виконано». Його варто дивитись окремо за типами: заміна лампи й ремонт покрівлі не порівнюються між собою.
• Частка повторних звернень. Скільки заявок за тією самою адресою й темою повернулось протягом місяця. Це перевірка якості, а не швидкості.
• Середня оцінка. Має сенс тільки разом із кількістю оцінок: чотири зірки від трьох людей не кажуть нічого.

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

За чим порівнювати сервіси

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

Про заявку

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

Про виконавця

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

Про керівника

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

Про будинок і дані

• Скільки обʼєктів вміщується в один обліковий запис.
• Чи розділені ролі й доступи.
• Що станеться з вашими даними, якщо ви підете.

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

Чому чат цього не дає

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

Ламається він на чотирьох речах.

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

І головне: у чаті немає межі між зверненням і розмовою. Тому заявка легко перетворюється на обговорення, а обговорення — на сварку.

Як це влаштовано у «Вдома»

Нижче — ті самі шість кроків в екосистемі «Вдома». Це переказ того, що написано на сторінках продукту; перевіряти його варто на демо.

• Подання. Мешканець створює заявку в застосунку: достатньо фотографії — ШІ розпізнає зображення й сам формує опис, мешканцю лишається підтвердити. Менеджер може створити заявку просто в смартфоні під час телефонної розмови, не кажучи «напишіть звернення».
• Класифікація. Звернення пріоритезуються: система допомагає визначити найважливіші заявки й братися за них першими.
• Призначення виконавця. У застосунку менеджера виконавець обирається в один дотик, у веб-порталі заявку передають майстрові або іншому працівникові. Для зовнішніх підрядників у конструкторі модулів є окремий платний модуль доступу — у базовий пакет він не входить.
• Статус. Статус заявки видно з обох боків: менеджер контролює виконання у веб-порталі, а застосунок майстра фільтрує заявки за статусом і пріоритетом. Листування теж іде в межах конкретної заявки, а не в загальному чаті будинку.
• Закриття. Майстер бачить призначене завдання з фото й адресою мешканця і прикріплює фото виконаних робіт прямо в заявку.
• Оцінка. Мешканець оцінює роботу після виконання. Оцінки й час реагування збираються в аналітику роботи команди разом із відсотком виконаних звернень, динамікою кількості заявок за періодами й порівнянням із попереднім періодом.

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

Як це складається в роботу команди — на сторінках «Вдома» для ОСББ і «Вдома» для керівних компаній.

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

«Написано на сторінці» і «працює у вашому будинку» — різні речі, і це стосується будь-якого сервісу, нашого теж.

Попросіть показати на живих даних:

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

Пʼять питань займають пів години — і це найдешевша частина вибору.