5-стъпковият работен процес за оплаквания от живущи, който всеки домоуправител има нужда от

Ако обработвате оплаквания за прехраната си и никога не сте записвали работния си процес, вие пак имате такъв. Той просто живее в главата ви и се измества леко всеки вторник. Тази статия очертава каноничния 5-стъпков работен процес, към който всеки бизнес за управление на сгради в крайна сметка се сближава, и посочва четирите места, където повечето управители изпускат информация.

Стъпка 1: Записване

Оплакването се докладва. Тук започват 80% от всички проблеми, защото форматът на записването определя всичко надолу по веригата.

Лошо записване: “Асансьорът не работи.” Публикувано в чата на сградата в 23 ч.

Какво липсва? Кой асансьор, ако има повече от един. На кой етаж е заседнал. Дали има някой вътре. Дали е повреден от час или от три дни. Дали живущият е опитал нещо.

Добро записване: структурирана форма със заглавие, описание, по избор категория и по избор снимка. Дори когато живущите я попълват мързеливо, получавате повече използваема информация, отколкото дава едно съобщение в чат, защото структурата ги принуждава да отговорят на основните въпроси.

Най-голямата печалба от напускането на чата е принуждаването на формата на записване. Живущите дават по-добра информация, когато формата я изисква, отколкото когато пишат свободно.

Често срещан начин на провал: записване на оплаквания по телефона. Информацията живее в главата на управителя, преписва се ненадеждно (или изобщо не) и никога не се появява в никаква система. Докато управителят забрави да предприеме действие по нея, няма никаква следа.

Стъпка 2: Триаж

Оплакването съществува. Сега някой трябва да реши: кой се заема с него?

В малка операция това е управителят, който го прави ръчно. В която и да е операция отвъд три сгради това се автоматизира по категория:

• ВиК → водопроводчик от състава
• Електро → електротехник от състава
• Борба с вредители → доставчик за дезинсекция
• Общи части / пожарна безопасност / “друго” → управител

Ако оплакването няма категория, по подразбиране се насочва към управителя. Ако има категория, но никой не е регистриран за нея, също се насочва към управителя и тази празнина се превръща в подсказка, че трябва да въведете изпълнител за това умение.

Ние поддържаме насочване на всяко оплакване към управителя независимо от типа и много екипи работят така. Но това е по-малко ефективният вариант: управителят се превръща в маршрутизатор и слоят на насочването се превръща в тясното място. Насочването по категория вместо това, при което управителят надзирава операцията, а не обработва всяко предаване, е промяната с най-висока възвръщаемост в целия работен процес.

Стъпка 3: Потвърждаване на приемане

Изпълняващият (управител или изпълнител) получава проблема и потвърждава приемането му. В система за заявки това означава преместване на статуса от Нов в В процес. Живущият вижда промяната на статуса и знае, че по проблема се работи. Не му се налага да пита.

Тази стъпка премахва целия цикъл “някакво развитие?”. Около 30% от всички излишъци от комуникацията в работен процес, базиран на чат, идват от това, че живущите питат за статус, защото нямат друг начин да знаят. Направете статуса видим и той изчезва.

Често срещан начин на провал: потвърждаване наум, но не в системата. Изпълняващият знае за проблема, но живущият не знае, че той знае. Живущият приема, че нищо не се случва, и докладва отново, често по-агресивно.

Стъпка 4: Решаване

Работата е свършена. Водопроводчикът е поправил теча. Електротехникът е сменил предпазителя. Чистачът е разчистил коридора.

В системата за заявки изпълняващият отбелязва проблема като решен (или “В очакване на потвърждение”: същото нещо, различен етикет). Това връща проблема към живущия за потвърждение. Изпълняващият не затваря заявката. Само живущият може да го направи, като потвърди поправката.

Това е съзнателно проектантско решение. То предотвратява провала, при който изпълнител поправя нещо наполовина и го отбелязва като затворено, после живущият се връща два дни по-късно с оплакване и вече има спор какво всъщност е било направено.

Често срещан начин на провал: изпълняващият сам затваря проблема; живущият никога не е уведомен; живущият докладва същия проблем отново две седмици по-късно, защото първоначалната поправка не е издържала.

Стъпка 5: Потвърждаване или повторно отваряне

Живущият получава известие. Два бутона: Потвърди поправката или Отвори отново с причина.

• Ако потвърди, проблемът се затваря. Готово. Не е нужно по-нататъшно действие от никого.
• Ако отвори отново, проблемът се връща в Нов с прикачена причина от живущия. Изпълняващият го вижда отново с пълен контекст.

Полето за причина при повторно отваряне е задължително. Това предотвратява мързеливото “още е счупено” повторно отваряне без информация, което принуждава нова обиколка.

Често срещан начин на провал: няма стъпка за потвърждение. Изпълняващият затваря; живущият никога не е попитан. Изпълняващият мисли, че проблемът е решен; живущият още живее с него. Това се появява по-късно като оплакване до собственика или, по-лошо, като отлив на живущ.

Къде изтича информация (и защо)

В петте стъпки ето четирите места, където информацията обикновено се губи:

1. Между Стъпка 1 и Стъпка 2, когато записването е неструктурирано. Информация, която не е попаднала в съобщението, никога не се възстановява. Решение: структурирана форма за записване.

2. Между Стъпка 2 и Стъпка 3, когато триажът е ръчен. Управителят знае за проблема, но му трябват 6 часа, за да го препрати на правилния изпълнител. Времето за отговор на изпълнителя се разтяга, защото часовникът е тръгнал много преди той да бъде уведомен. Решение: автоматично насочване по категория.

3. Между Стъпка 3 и Стъпка 4, когато статусът не е видим. Живущите питат за развитие, защото не могат да го видят. Управителите обясняват по три пъти. Решение: споделено поле за статус.

4. Между Стъпка 4 и Стъпка 5, когато потвърждението се пропуска. Изпълняващият затваря; живущият никога не потвърждава. Проблемът изглежда решен, но не е. Решение: стъпка за потвърждение от живущия.

Запушете тези четири течове и работният ви процес тръгва около 3× по-бързо със същия персонал.

Проверка на реалността с времето

Ако нанесете този работен процес върху реалното време на реално оплакване, ето как изглежда здравословният жизнен цикъл:

• Стъпка 1 (Записване): живущият подава за 30 секунди.
• Стъпка 2 (Триаж): системата насочва автоматично за <1 секунда.
• Стъпка 3 (Потвърждаване на приемане): изпълняващият отговаря в рамките на 4 часа в работни дни, обикновено.
• Стъпка 4 (Решаване): варира силно. Минути за отключена врата, дни за поръчка на части.
• Стъпка 5 (Потвърждаване): живущият потвърждава в рамките на 24 часа след като е попитан.

От край до край типичен проблем се затваря за 1-3 работни дни. Оплакванията, които отнемат 3 седмици, са бавни, защото стъпки 2, 3 или 5 липсват изцяло, не защото работата е трудна.

Ако средното ви време за решаване е повече от седмица, а изпълнителите ви не са тясното място, тогава работният процес е. Поправете първо работния процес.