På denne siden
Et team for kundestøtte endrer rutingen: Alle forespørsler merket «haster» går til en kø for spesialister. I et tenkt eksempel merker ansatte snart flere forespørsler som hastesaker fordi den køen svarer raskere. Regelen kjører fortsatt akkurat som skrevet. Inndataene den får, har endret seg fordi folk tilpasset seg.
En samtale om komplekse systemer skiller mellom faste deler og systemer der delene reagerer på hverandre. De brede historiske påstandene fra kilden trengs ikke her. Det praktiske spørsmålet er smalere: Endret tiltaket vårt atferden som leverer dataene våre?
En regel kan være riktig og likevel endre bevisene
I en enkel pipeline kommer et felt inn, en mapping omformer det, og målsystemet lagrer resultatet. Hvis kildefeltet har en stabil kontrakt, kan mappingen være vanlig kode med faste regler. Gjentatte kjøringer bør gi samme resultat for samme inndata.
Se så på en grense som påvirker folk. Hvis forespørsler merket «haster» får raskere hjelp, har de ansatte en grunn til å bruke merkelappen. Andelen hastesaker stiger. Et dashboard kan vise at spesialistkøen behandler mange hastesaker og konkludere med at regelen trengs mer enn før. Men dashboardet måler atferd under regelen, ikke verden uten den.
Det samme kan skje på tvers av SaaS-systemer. En markedsføringsplattform kan merke kunder med «høy interesse» ut fra klikk og så sende flere meldinger til den gruppen. Flere meldinger kan gi flere klikk. Hvis klikkene mates tilbake i gruppen uten omtanke, kan systemet forsterke sin egen klassifisering. Det er en tenkt mekanisme, ikke en påstand om at en bestemt plattform gjør dette.
| Spørsmål | Sjekk for fast vei | Sjekk av tilbakemelding |
|---|---|---|
| Kjørte regelen? | Sammenlign inndata og utdata med kontrakten | Fortsatt nødvendig |
| Ble resultatet bedre? | Sjekk det ønskede resultatet | Sjekk endret atferd og andre mulige årsaker |
| Er inndataene stabile? | Valider skjema og verdier | Undersøk om regelen endret hvem som lager inndataene |
| Kan vi rette en feil? | Beregn på nytt eller rull tilbake | Ta hensyn til virkninger som allerede har endret folk eller kampanjer |
Tabellen er en måte å stille spørsmål på. Den gjør ikke hver integrasjon til et problem i komplekse systemer.
Se etter kretsløpet, ikke moteordet
Et kretsløp av tilbakemelding har en bestemt form: En handling påvirker atferd, denne atferden endrer fremtidige inndata, og de endrede inndataene påvirker neste handling.
- Rutingbeslutningprioritet settespåvirker
- Servicesvartiden endresendrer
- Folk tilpasser segfremtidige merkelapper endresmates inn i
- Neste rutingbeslutningtilpassede merkelapper blir inndata
Tegn pilene før du bruker en teori. Hvis det ikke finnes en sannsynlig vei fra utdata tilbake til inndata, hold løsningen enkel.
For støttekøen er kretsløpet synlig. Ruteprioritet påvirker svartid. Svartid påvirker hvordan ansatte merker forespørsler. Merkelapper avgjør ruteprioritet. Teamet kan teste kretsløpet ved å sammenligne merkelapper, faktisk alvor, ventetider og omklassifiseringer før og etter regelen. Flere saker merket «haster» alene kan ikke fortelle om kundenes problemer ble verre eller merkelappen ble mer attraktiv.
Skillet beskytter også mot å reagere for sterkt. En midlertidig topp etter en regelendring kan skyldes at en restkø tømmes, en endring i rapportering eller en virkelig endring i etterspørsel. Én graf kan ikke identifisere årsaken. Behold de opprinnelige postene og noter regelendringer, slik at senere lesere vet hvilket system som skapte dataene.
Følg bare reglene som kan endre sine egne inndata
Stabile mappinger trenger ikke en samfunnsvitenskapelig studie. Det ekstra arbeidet hører hjemme der en regel endrer menneskers insentiver, kundens opplevelse eller fremtidige data som brukes til å vurdere den samme regelen. Et enkelt spørsmål finner kandidatene: Kan noen før dette steget se eller merke resultatet fra regelen og endre det de sender neste gang? Hvis ja, navngi ett resultat og én mulig tilpasning å følge med på.
Noen atferdsendringer er ønskelige. Hvis tydeligere feilmeldinger får brukere til å rette dårlige poster tidligere, blir inndataene bedre. Målet er ikke å fryse atferd. Målet er å unngå å forveksle en reaksjon på systemet med uavhengig informasjon om verden.
Gå gjennom regelen med en hyppighet som passer konsekvensene. En merkelapp i en kø med lav risiko kan sjekkes ukentlig. En regel som holder tilbake kampanjer på grunn av samtykke, må håndheves med en gang og kontrolleres på en annen måte. Å analysere tilbakemelding svekker aldri krav om tillatelse eller samtykke.
En annen nyttig test er å sammenligne inndata før og etter at de som påvirkes av regelen, fikk vite om den. Hvis fordelingen endrer seg, snakk med medarbeiderne før du bestemmer årsaken. De kan ha funnet en tydeligere merkelapp, laget en omvei rundt en forsinkelse eller møtt en virkelig annen blanding av saker. Behold en uforanderlig post om regelversjon og starttidspunkt, slik at senere analyser kan gjenskape hvilken regel som formet hvilke data. Dette er samme disiplin som en plan for integrerte arbeidsflyter trenger for vanlig dataeierskap, utvidet til atferd som endres fordi arbeidsflyten selv endret seg.
En regel blir en del av miljøet når folk kan reagere på den. Hold mekanikken regelstyrt og gjentakbar. Fortsett å teste resultatet.
Ofte Stilte Spørsmål
Hvordan kan tilbakemelding endre en arbeidsflyt i en bedrift?
En regel kan endre insentiver eller hvordan ansatte handler. En ny grense for ruting kan for eksempel få folk til å klassifisere forespørsler annerledes. Da endres dataene som senere ser ut til å bekrefte grensen.
Gjør det alle synkroniseringer uforutsigbare?
Nei. Mange mappinger og kontrakter forblir stabile. Tilbakemelding betyr noe der regelen endrer atferd før eller etter den. Test om det skjer før du legger til kompleksitet.
Hva bør et team følge med på etter en regelendring?
Følg det ønskede resultatet, unntak, manuelle rettelser og endringer i fordelingen av inndata. Sammenlign med før endringen og noter andre mulige årsaker til bevegelsen.