Sådan ser et struktureret system til fejlmeldinger ud for administratorer

En ticket er en simpel post. Den er også den vigtigste byggesten i moderne driftsarbejde, fra kundeservice i et flyselskab til hændelsesstyring på et hospital og vedligeholdelse af en ejendom.

Denne artikel forklarer, hvad en ticket er (i en ejendom: en fejlmelding), hvad der gør systemet omkring den nyttigt, og hvad der ændrer sig, når du driver ejendomsadministration med et.

En ticket er bare en post med fire egenskaber

Skræl jargonen af, og en ticket er en opgave med fire oplysninger knyttet til sig:

1. Et id, som regel et nummer som #0042. Så du kan henvise til den, uden at der er tvivl.
2. En status, hvor den er i forløbet. Ny, I gang, Afventer bekræftelse, Lukket.
3. En ansvarlig, den person, der lige nu skal føre den videre.
4. En historik, hver ændring, nogen har lavet, med dato og klokkeslæt.

Det er det. Alt andet (kategorier, prioriteter, vedhæftede filer, kommentarer) er valgfri pynt. De fire egenskaber gør en klage til en opgave, der bliver fulgt, i stedet for en glemt besked.

Sammenlign det med en besked i Facebook-gruppen. En besked har indhold. Det er det. Den har intet id (ud over sin plads i strømmen), ingen status, ingen ansvarlig og ingen historik. Derfor kan du ikke drive en arbejdsgang oven på den.

Hvorfor hver af de fire egenskaber betyder noget

Id

Når to personer taler om en fejlmelding, skal de vide, at de taler om den samme. I en Facebook-gruppe gør du det ved at citere: »det med elevatoren i går« eller »det utætte rør i 4. th., som VVS’eren sagde var en pakning«. Så snart du har mere end fem åbne fejlmeldinger ad gangen, bliver det tvetydigt.

Et nummer på fejlmeldingen (#0042, #0089) løser det for altid. Enhver beboer, administrator eller håndværker kan henvise til en fejlmelding med dens nummer uden den mindste tvivl. Det lyder som en bagatel. Det fjerner omkring 15 % af al forvirringen i en typisk arbejdsgang hos en administrator.

Status

Status gør en fri samtale til en tilstandsmaskine:

Beboeren behøver ikke spørge »nyt?«. Beboeren kan se status. Administratoren behøver ikke huske, hvilke fejlmeldinger der venter på VVS’eren. Administratoren filtrerer på status. Og den, der leder virksomheden, behøver ikke læse 200 beskeder for at vide, hvor mange fejlmeldinger der er åbne denne måned. Det er bare at tælle.

Status er også der, hvor automatiseringen bor. Når status ændrer sig, sker der noget: notifikationer bliver sendt, beboerne får besked, håndværkere bliver tildelt. I en Facebook-gruppe er det umuligt, fordi chatten ikke kender til status.

Ansvarlig

Hver fejlmelding har på ethvert tidspunkt i sit forløb præcis én person, der er ansvarlig for at føre den videre. Når beboeren opretter den, er den ansvarlige ejendommens administrator (eller den håndværker, den er sendt til). Når administratoren tildeler den til en håndværker, bliver håndværkeren ansvarlig. Når håndværkeren melder den klar, bliver beboeren ansvarlig og skal bekræfte eller genåbne.

Det er den ene funktion, der gør op med gruppens »det tager en anden sig nok af«, hvor alle ser fejlmeldingen, og ingen tager sig af den.

Historik

En komplet log over hver statusændring, hver tildeling og hver kommentar. Afgørende af tre grunde:

1. Ansvarlighed. Når generalforsamlingssæsonen kommer, kan du vise en præcis tidslinje for, hvordan hver fejlmelding blev håndteret.
2. Mønstre. Efter seks måneder opdager du, at 40 % af dine VVS-fejlmeldinger kommer fra den samme ejendom: et tegn på, at det er tid til at sætte udskiftning af faldstammerne på dagsordenen til generalforsamlingen.
3. Nye kolleger. Når en ny administrator starter på kontoret, kan den nye kollega gå historikken for enhver ejendom igennem og forstå, hvad der foregår.

Hvad »systemet omkring« fejlmeldingerne tilføjer

En fejlmelding i sig selv er en post. Et system til fejlmeldinger tilføjer arbejdsgangen omkring den:

• Fordeling. Når en fejlmelding bliver oprettet, hvem får den så? De fleste systemer bruger regler: »kategori = VVS → tildel VVS’er X«. Administratoren skal ikke bestemme det.
• Notifikationer. Når status ændrer sig, hvem får så besked? Den ansvarlige, den, der meldte fejlen, og nogle gange andre, der følger sagen.
• Filtre. »Vis mig alle nye fejlmeldinger i Lindevej 12, som ingen har fået tildelt, og som er mere end 24 timer gamle.« To klik.
• Massehandlinger. »Luk de 30 fejlmeldinger, der har afventet bekræftelse i mere end to uger.« Én handling.

Intet af det findes i en arbejdsgang, der kører gennem en Facebook-gruppe. Der er ingen måde at »filtrere alle åbne fejlmeldinger i fire ejendomme« i Messenger, fordi intet i Messenger ved, hvad en »åben fejlmelding« er.

Den mindste brugbare arbejdsgang for en ejendom

Du har ikke brug for en virksomhedsplatform med 200 funktioner. Den mindste brugbare arbejdsgang for fejlmeldinger i ejendomsadministration har:

• Titel + beskrivelse + valgfri kategori + valgfrit billede. Selve fejlmeldingen.
• Et statusfelt med højst 5 værdier. Ny, I gang, Afventer bekræftelse, Lukket, Genåbnet. Mere end det er overkill.
• Tildeling til en af tre roller. Administrator, håndværker, beboer.
• Pushbeskeder ved tildeling og statusændring. Så ingen behøver åbne appen for at opdage, at der er sket noget.
• Adskillelse pr. ejendom. Hver fejlmelding hører til en ejendom, og hver bruger ser kun de ejendomme, vedkommende er med i.

Det er hele kernen. Tilbyder et værktøj dig det, i en brugerflade som beboerne kan bruge uden oplæring, har du det, du skal bruge.

Indvendingerne, der altid kommer

»Mine beboere kommer aldrig til at bruge det.«

Omkring 70 % gør. De sidste 30 % skriver til en nabo, der bruger det, og naboen lægger fejlmeldingen ind. Du behøver ikke 100 % for at høste gevinsterne. Du behøver nok til, at indbakken med fejlmeldinger bliver den ene sandhed.

»Vi prøvede med e-mail, og det virkede ikke.«

E-mail er ikke et system til fejlmeldinger. E-mail har ingen status, ingen fælles indbakke, ingen tildeling, ingen filtre og ingen fordeling. Det går galt at bruge e-mail som et system til fejlmeldinger, fordi det ikke er et.

»Vi har allerede et regneark til det.«

Et regneark ligner et system til fejlmeldinger mere, end en Facebook-gruppe gør. Det har id’er og en slags statuskolonne. Men det har stadig ingen notifikationer, intet samarbejde i realtid, intet, som beboerne kan se, og ingen automatisering. Det er en registrering af arbejdet. Det er ikke en arbejdsgang.

Skiftet i tankegang

Det sværeste ved at gå over til et system til fejlmeldinger er det mentale skift fra »systemet, det er mig« til »systemet er systemet, og jeg holder øje med det«. De administratorer, der tager det til sig, vokser langt ud over den portefølje, de havde før. De, der ikke gør, bliver ved med at være det menneskelige omstillingsbord, til de brænder ud.

Den første uge føles mærkelig, fordi du ikke svarer på noget hele tiden. Så går det op for dig, at ejendommene kører, uden at du griber ind i realtid, og grunden er, at selve arbejdsgangen gør det arbejde, der før lå i dit hoved.