← Alle innlegg

Én operativ liste: serviceforespørsler og jobber i samme arbeidsflate

Se hvordan Operations samler forespørsler, jobber, planlegging og ressurser i én filtrert liste uten å bli en tredje tilstandsmaskin.

Arbeid i front office finnes i to former samtidig. En Service Request beskriver hva kunden ba om, mens en Job beskriver hva virksomheten nå skylder kunden. Skillet er nettopp det som hindrer en samtalestatus i å utgi seg for å være en arbeidsprosess — men det betydde også at en disponent måtte lese to lister og koble dem sammen i hodet for å svare på noe så enkelt som «hva er åpent akkurat nå?».

Én rad per forespørsel, og jobben den ble til

En rad er en forespørsel pluss jobben den ble til, dersom den ble det. Tre visninger ligger øverst: Alle viser alt uansett stadium, Forespørsler avgrenser til arbeid som ennå ikke er booket til en jobb, og Jobber avgrenser til forespørsler som allerede har produsert en arbeidsordre. Hver visning henter tellingen fra samme spørring som fylte listen, så tallet og radene kan aldri være uenige.

Kolonner for disponering, og en adresse som bare markeres der den blokkerer

Kolonnene er valgt for disponering, ikke for support: arbeidsnummer, kunde, tjeneste, adresse, begge statusene i samme rad og tidspunktet for et bekreftet besøk. En manglende adresse blir bare markert der den faktisk blokkerer noe — når forespørselen er klar for planlegging, eller når en jobb finnes og verken er fullført eller avlyst. En forespørsel som fortsatt kvalifiseres, får være ufullstendig i fred.

Filtre, fasetter og masseoverganger som er gyldige for hver rad

Filtrene følger samme logikk. Tjenestefilteret bygges av fasetter serveren returnerer med siden, slik at hvert valg kan vise hvor mange forespørsler tjenesten skapte og hvor mange som ble arbeid. Statusfilteret bytter alternativer med stadiet, og søket dekker forespørsels- og jobbnummer, sammendrag, kundenavn, e-post, telefon, tjenestenavn, adresse og by. Masseoverganger tilbys bare når de er gyldige for hver eneste valgte rad.

En sammenkoblet liste, ikke en tredje tilstandsmaskin

Under overflaten er flaten bevisst tynn. Store-en eier filtrene og leseprojeksjonen og ingenting mer: kvalifisering hører fortsatt hjemme i forespørsels-store-en, og livssyklusendringer i jobb-store-en. En sammenkoblet liste er en praktisk måte å se to domener på, og må ikke stille bli et tredje sted der reglene deres avgjøres.

Ta morgensjekken fra én visning i stedet for tre

Åpne dagen i Alle og prioriter etter hva statusene sier, ikke etter hva som kom sist. Forespørsler under kvalifisering venter på et svar, handoff venter på et menneske, og klar for planlegging venter på en time. Alt med en jobb har allerede forlatt samtalen.

Les tjenestefilteret som en ukentlig måling. Hvert valg viser hvor mange forespørsler tjenesten skapte og hvor mange som ble arbeid, og jevn pågang med nesten ingen konvertering peker som regel på en mal som spør om noe kunden ikke vet.

Behandle en markert manglende adresse som et avbrudd. Markeringen dukker først opp når noen allerede har forpliktet seg til å møte opp, så rett den fra forespørselspanelet mens samtalen er åpen — teknikerbriefen fryses ved booking.

Ofte stilt spørsmål

Holdes forespørsler og jobber atskilt når de deler én liste?

Ja. Operations er en sammenkoblet leseprojeksjon: den eier filtrene og listen, mens kvalifisering fortsatt skrives gjennom forespørsels-store-en og livssyklusendringer gjennom jobb-store-en. En forespørsel beskriver hva kunden ba om og en jobb hva virksomheten skylder, og ingen av tilstandsmaskinene endres av at begge vises i samme rad.