Når feedback ændrer systemet

Et supportteam ændrer sin regel for fordeling: Alle anmodninger markeret som »haster« går til en specialistkø. I et tænkt eksempel markerer medarbejderne snart flere anmodninger som hastende, fordi køen svarer hurtigere. Reglen kører præcis som skrevet. Inputtet har ændret sig, fordi folk har tilpasset sig den.

En samtale om komplekse systemer skelner mellem faste dele og systemer, hvis dele reagerer på hinanden. Dens brede historiske påstande er ikke nødvendige her. Det praktiske spørgsmål er snævrere: Ændrede vores indgreb den adfærd, der skaber vores data?

En regel kan være korrekt og alligevel ændre beviset

I en enkel datakæde ankommer et felt, en mapping ændrer det, og destinationen gemmer resultatet. Hvis feltet i kilden har en stabil aftale, kan mappingen være almindelig, deterministisk kode. Gentagne kørsler bør give samme output for samme input.

Se nu en tærskel, som påvirker mennesker. Hvis »hastende« anmodninger får hurtigere hjælp, har medarbejderne en grund til at bruge mærket. Andelen af hastende anmodninger stiger. Et dashboard kan vise, at specialistkøen behandler mange hastende sager, og konkludere, at reglen er mere nødvendig end nogensinde. Men dashboardet måler adfærd under reglen, ikke den uberørte verden før den.

Samme problem kan opstå mellem SaaS-systemer. En marketingplatform kan mærke kunder med »høj interesse« ud fra klik og derefter sende flere beskeder til segmentet. Flere beskeder kan skabe flere klik. Hvis klik uden omtanke føres tilbage til segmentet, kan systemet forstærke sin egen klassificering. Det er en tænkt mekanisme, ikke en påstand om at en bestemt platform gør det.

Spørgsmål	Kontrol af fast vej	Kontrol af feedback
Blev reglen kørt?	Sammenlign input og output med aftalen	Stadig nødvendigt
Blev resultatet bedre?	Kontrollér det tilsigtede resultat	Se på adfærdsændringer og andre årsager
Er input stabilt?	Kontrollér skema og værdier	Undersøg, om reglen ændrede, hvem der skaber input
Kan vi rette fejlen?	Beregn igen eller rul tilbage	Tænk på virkninger, der allerede er skabt hos mennesker eller i kampagner

Tabellen er et begrebsmæssigt redskab til at undersøge problemet. Den gør ikke alle integrationer til et problem om komplekse systemer.

Se efter kredsløbet, ikke modeordet

Et feedbackkredsløb har en bestemt form: En handling påvirker adfærd, adfærden ændrer et fremtidigt input, og det ændrede input påvirker næste handling.

1. Beslutning om fordeling

   prioritet sættes
   påvirker
2. Service

   svartid ændres
   ændrer
3. Folk tilpasser sig

   fremtidige mærker ændres
   indgår i
4. Næste fordeling

   ændrede mærker bliver input

Tegn pilene, før du bruger en teori. Hvis der ikke er en plausibel vej fra output tilbage til input, så hold designet enkelt.

I supportkøen er kredsløbet synligt. Prioritet påvirker svartid. Svartid påvirker, hvordan medarbejderne mærker anmodninger. Mærkerne bestemmer prioriteten. Teamet kan teste kredsløbet ved at sammenligne mærker, faktisk alvor, ventetid og omklassificering før og efter reglen. Flere mærker med »haster« fortæller ikke i sig selv, om kundernes problemer blev værre, eller mærket blev mere attraktivt.

Skellet beskytter også mod overreaktion. Et midlertidigt spring efter en politikændring kan skyldes, at en ophobet kø bliver afviklet, at rapporteringen ændres, eller at efterspørgslen faktisk flytter sig. Ét diagram kan ikke finde årsagen. Gem de oprindelige poster, og noter ændringer i reglen, så senere læsere ved, hvilket system der skabte dataene.

Hold kun øje med regler, der kan ændre deres eget input

Stabile mappings kræver ikke et studie af menneskers adfærd. Det ekstra arbejde hører til, hvor en regel ændrer en persons incitament, en kundes oplevelse eller fremtidige data, som den samme regel bedømmes med. Et enkelt spørgsmål kan finde kandidaterne: Kan nogen før reglen se eller mærke dens output og ændre det, de sender næste gang? Hvis ja, så vælg ét resultat og én mulig tilpasning at holde øje med.

Nogle adfærdsændringer er ønskelige. Hvis klarere fejlbeskeder får brugerne til at rette dårlige poster tidligere, bliver datastrømmen bedre. Målet er ikke at fryse adfærd. Det er at undgå at forveksle en reaktion på systemet med uafhængigt bevis om verden.

Gennemgå reglen med en hyppighed, der passer til dens konsekvenser. Et kømærke med lav risiko kan måske undersøges ugentligt. En kampagneregel, der udelukker kunder ud fra samtykke, skal håndhæves straks og kontrolleres på en anden måde. Analyse af feedback løsner aldrig krav om adgang eller samtykke.

En anden nyttig test er at sammenligne reglens input før og efter, at dem der påvirkes, lærer reglen at kende. Hvis fordelingen flytter sig, så tal med medarbejderne, før du udpeger en årsag. De kan have fundet et klarere mærke, arbejdet uden om en forsinkelse eller fået en reelt anden blanding af anmodninger. Gem en uforanderlig registrering af reglens version og starttidspunkt, så en senere analytiker kan se, hvilken politik der formede hvilke data. Det er samme disciplin, som en plan for integration af arbejdsgange behøver til almindeligt ejerskab af data, her udvidet til adfærd, som ændres af selve arbejdsgangen.

En regel bliver en del af sit miljø, når folk kan reagere på den. Hold dens præcise mekanik deterministisk. Bliv ved med at teste resultatet.