Jak vypadá strukturovaný ticketovací systém pro správce budov

Ticket je prostý záznam. Je to také nejdůležitější strukturální primitiv v moderní provozní práci, od zákaznické podpory aerolinek přes řízení incidentů v nemocnicích až po údržbu budov.

Tento článek vysvětluje, co je ticket, čím je systém kolem ticketů užitečný a co se změní, když na něj přesunete správu budov.

Ticket je jen záznam se čtyřmi vlastnostmi

Odstraňte žargon a ticket je kus práce se čtyřmi kusy připojených metadat:

1. Identifikátor, obvykle číslo jako #0042. Abyste na něj mohli odkazovat bez nejasností.
2. Stav, kde se v pracovním postupu nachází. Nový, Probíhá, Čeká na potvrzení, Uzavřeno.
3. Odpovědná osoba, člověk, který ho právě má posunout dál.
4. Historie, každá změna, kterou kdokoli udělal, s časovými razítky.

To je vše. Všechno ostatní (kategorie, priority, přílohy, komentáře) je volitelná dekorace. Čtyři výše uvedené vlastnosti promění stížnost ve sledovaný úkol místo zapomenuté zprávy.

Porovnejte to se zprávou v chatu. Zpráva v chatu má obsah. To je vše. Nemá identifikátor (jiný než svou pozici v rolování), žádný stav, žádnou odpovědnou osobu, žádnou historii. Proto na ní nemůžete provozovat pracovní postup.

Proč na čtyřech vlastnostech záleží jednotlivě

Identifikátor

Když dva lidé řeší problém, potřebují vědět, že mluví o tomtéž problému. V chatu to děláte citováním: „ta věc s výtahem z včerejška“ nebo „ten únik v 4B, o kterém instalatér řekl, že je to těsnění“. Jakmile má váš byznys víc než pět souběžných problémů, začne to být nejednoznačné.

Číslo ticketu (#0042, #0089) to vyřeší navždy. Kterýkoli nájemník, správce nebo řemeslník může na ticket odkázat jeho číslem s nulovou nejednoznačností. Zní to triviálně. Odstraní to asi 15 % všeho zmatku v typickém postupu správy.

Stav

Ve stavu se děje to kouzlo. Stav převádí volnou konverzaci na stavový automat:

Nájemník se nemusí ptát „nějaká novinka?“. Vidí stav. Správce si nemusí pamatovat, které problémy blokuje instalatér. Filtruje podle stavu. Vlastník nemusí číst 200 zpráv, aby zjistil, kolik problémů je tento měsíc otevřených. Spočítá je.

Stav je také místo, kde žije automatizace. Když se stav změní, dějí se věci: spustí se oznámení, nájemníkům přijde ping, řemeslníci jsou přiřazeni. To je v chatu nemožné, protože chat nemá ponětí o stavu.

Odpovědná osoba

Každý ticket má v každém okamžiku svého životního cyklu přesně jednoho člověka odpovědného za to, aby ho posunul dál. Když nájemník podá hlášení, odpovědnou osobou je správce budovy (nebo nasměrovaný řemeslník). Když ho správce přiřadí řemeslníkovi, odpovědnou osobou se stane řemeslník. Když ho řemeslník označí za hotový, odpovědnou osobou se stane nájemník. Musí potvrdit nebo znovu otevřít.

Tohle je jediná funkce, která láme „tragédii obecní pastviny“ skupinového chatu, kde problém vidí všichni a nikdo ho nevyřídí.

Historie

Úplný log každé změny stavu, každého přiřazení, každého komentáře. Klíčový ze tří důvodů:

1. Odpovědnost. Když přijde sezona shromáždění, dokážete vytvořit přesnou časovou osu toho, jak byl každý problém vyřízen.
2. Detekce vzorců. Po půl roce zjistíte, že 40 % vašich problémů s vodou je ve stejné budově, což ukazuje na strukturální problém, který musí vlastník řešit.
3. Onboarding. Když se přidá nový správce, může se prorolovat historií kterékoli budovy a pochopit, co se děje.

Co přidává „systém kolem ticketů“

Ticket sám o sobě je záznam. Ticketovací systém přidává pracovní postup kolem něj:

• Směrování. Když se ticket vytvoří, ke komu jde? Většina ticketovacích systémů používá pravidla: „kategorie = voda → přiřaď instalatérovi X“. Správce nerozhoduje.
• Oznámení. Když se stav změní, komu přijde ping? Odpovědné osobě, oznamovateli, někdy pozorovateli.
• Filtrování. „Ukaž mi všechny Nové tickety v budově 12, nepřiřazené, starší než 24 hodin.“ Dvě kliknutí.
• Hromadné akce. „Zavři 30 ticketů, které jsou ve stavu Čeká na potvrzení déle než dva týdny.“ Jedna akce.

Tyto operace v postupu na bázi chatu neexistují. Neexistuje způsob, jak „vyfiltrovat všechny otevřené problémy napříč čtyřmi budovami“ na WhatsAppu, protože nic na WhatsAppu neví, co je „otevřený problém“.

Minimální funkční ticketovací postup pro budovu

Nepotřebujete podnikovou platformu s 200 funkcemi. Minimální užitečný ticketovací postup pro správu nemovitostí má:

• Název + popis + volitelná kategorie + volitelná fotka. Samotné hlášení.
• Pole stavu s nejvýše 5 hodnotami. Nový, Probíhá, Čeká na potvrzení, Uzavřeno, Znovu otevřeno. Cokoli víc je překombinování.
• Přiřazení jedné ze tří rolí. Správce, řemeslník, nájemník.
• Push notifikace při přiřazení a změně stavu. Aby lidé nemuseli otevírat aplikaci, aby zjistili, že se něco stalo.
• Rozsah na úrovni budovy. Každý ticket patří k budově, každý uživatel vidí jen budovy, jejichž je členem.

To je celé jádro. Pokud vám nástroj tohle nabídne v rozhraní, které nájemníci zvládnou bez školení, máte, co potřebujete.

Námitky, které vždycky padnou

„Moji nájemníci tohle nikdy nepoužijí.“

Asi 70 % ano. Dalších 30 % napíše nájemníkovi, který ho používá, a ten problém přepíše. Nepotřebujete 100% zapojení, abyste získali provozní přínosy. Potřebujete dost zapojení, aby se schránka stala zdrojem pravdy.

„Zkusili jsme to e-mailem a nefungovalo to.“

E-mail není ticketovací systém. E-mail nemá stav, sdílenou schránku, přiřazení, filtr ani směrování. Zacházet s e-mailem jako s ticketovacím systémem selhává, protože e-mail jím není.

„Na tohle už máme excelovou tabulku.“

Excelová tabulka má k ticketovacímu systému blíž než skupinový chat. Má identifikátory a jakýsi sloupec stavu. Pořád nemá oznámení, spolupráci v reálném čase, plochu pro nájemníky ani automatizaci. Je to záznam práce. Není to pracovní postup.

Posun v myšlení

Nejtěžší na přechodu na ticketovací systém je mentální posun od „já jsem ten systém“ k „systém je ten systém a já na něj dohlížím“. Správci, kteří si tohle zvnitřní, vyrostou na 10+ budov. Správci, kteří ne, jsou dál lidským směrovačem, dokud nevyhoří.

První týden je divný, protože nereagujete pořád. Pak si uvědomíte, že budovy běží hladce bez vašeho zásahu v reálném čase, a důvodem je, že pracovní postup sám dělá práci, která dřív žila ve vaší hlavě.

A o tom to celé je.