Vad kostar verktyget när någon ska använda det?

Vad ska någon kunna göra bättre?

I samtalet ställer jag frågorna om vad en tjänst underlättar, hur mycket tid den sparar och vad människorna ska göra med tiden i stället. Det är där jag vill börja en diskussion om ännu ett verktyg.

Ett lägre pris kan vara intressant. En ny funktion kan också vara intressant. Men om ingen kan beskriva vilket arbete som ska förbättras blir det svårt att bedöma om köpet löste något. Det går att få en snyggare bild av samma situation och fortfarande vara lika osäker på nästa steg.

Försök göra uppdraget begripligt innan ni jämför alternativen. Är det ett återkommande manuellt arbete som behöver gå snabbare? Saknas information när någon ska fatta ett beslut? Eller behöver kunden kunna göra något som i dag kräver hjälp? Olika problem ger olika krav.

Räkna med arbetet på båda sidor om fakturan.

Fredrik lyfter relationen mellan priset för tjänsten och vad det skulle kosta att utveckla och underhålla något själv. Jag tar också upp tiden för integrationen. Tillsammans gör de frågorna jämförelsen mer användbar än att bara ställa två månadspriser bredvid varandra.

Det finns en kostnad i att börja använda ett verktyg och en kostnad i att fortsätta få nytta av det. Någon behöver förstå hur det fungerar, hålla ordning på underlaget och märka när resultatet blivit fel eller slutat vara relevant.

Jämför en färdig tjänst med ett eget bygge genom samma uppgift. Ta med tiden att koppla ihop system, kontrollera resultat och underhålla lösningen. Ett lågt månadspris säger ganska lite om den totala arbetsinsatsen.

En liten intern fråga kan vara värd ett eget verktyg.

Jag berättar i avsnittet om en kollega som byggt ett internt verktyg för att följa innehåll som anställda producerar. Utgångspunkten var en konkret fråga: hur går det för det materialet och hur kan teamet få återkoppling på det?

Jag blir glad när tekniken gör sådana försök möjliga. Samtidigt behöver även ett internt verktyg bedömas efter vad det hjälper människor att förstå. Om en ranking ska användas i teamet behöver de som ser den veta vilka parametrar den bygger på och vad den är till för.

Delarna behöver kunna arbeta med samma verklighet.

Fredrik tar upp problemet med data som ligger utspridd i olika tjänster. Vi kommer också in på kopplingar mellan system. Bakom tekniksnacket finns en väldigt praktisk fråga: kan vi få ihop den information som behövs för arbetet?

I diskussionen om leveranser beskriver jag hur information om plock, hämtning och transport kan påverka vad vi kan berätta för kunden. Det är flera led som tillsammans behöver ge ett trovärdigt besked. En fin ruta på produktsidan hjälper begränsat om den inte hänger ihop med det som sedan händer.

Här vill jag att behovet får styra hur vi ser på systemet. Vad behöver vara tillgängligt, vad behöver vara korrekt och vem märker om något slutar stämma? Det blir lättare att ställa sådana frågor när man utgår från arbetsuppgiften eller kundens situation.

Ställ samma fråga till det ni köper i marketing.

Senare i avsnittet diskuterar vi influencer marketing och kreatörer. Jag beskriver hur vi har omprövat utrymmet för kanalen i vårt eget arbete. Det är en återblick på vårt resonemang i samtalet, inte en färdig dom över varje samarbete.

Vi skiljer också mellan att köpa tillgång till en persons följare och att få ett innehåll som kan användas i annonsering. Det är olika saker att bedöma. Om vi inte är tydliga med vad vi försöker få ut av samarbetet blir det lätt att prata förbi varandra när utfallet ska utvärderas.

Precis som med ett systemköp vill jag kunna förstå uppdraget och kostnaden. Vilken del av arbetet hjälper samarbetet oss med? Hur ska materialet användas? Vad har vi lärt oss som påverkar nästa val? Då blir diskussionen mer konkret än om en kanal känns modern eller omodern.

Det som ser enkelt ut för kunden kan kräva flera fungerande led.

När vi pratar om returflöden kommer vi in på ett konkret teknikproblem. Kunden gör något på sajten, men ordern kan redan ha skickats vidare till ett externt lager och vara på väg att plockas. Ett önskemål i gränssnittet behöver alltså möta en verklig process bakom.

Det är ett bra exempel på varför en uppgift inte är löst bara för att en knapp syns. Någon behöver förstå vad som händer när den används och vilken information kunden får tillbaka. Annars kan den enkla ytan dölja ett nytt ärende för kundservice.

Innan ni lägger till knappen: följ en riktig order genom lagerflödet. När går den att ändra, vilket besked kan kunden få och vem tar hand om det som inte går att automatisera? Det behöver vara löst för att funktionen ska gå att lita på.