BykiMötet gick bra. Kunden pratade länge om vad som skaver, du nickade och antecknade lite. Två dagar senare sätter du dig för att skriva ett förslag.
Då märker du hur lite du minns. Du kommer ihåg känslan av mötet, men inte exakt vad kunden sa om tidsramen. Var budgeten nämnd, eller var det du som gissade? Var det ekonomichefen eller vd:n som skulle bestämma?
Förslaget blir ändå skrivet. Det ser proffsigt ut. Men det beskriver det du minns, inte det kunden sa.
Uppdragsbeskrivningen kommer före offerten
Det finns mycket att vinna på en snygg offert. AI-verktyg kan i dag ta fram en hel presentationssida åt dig med diagram och kalkyler. Men ju snyggare förslaget är, desto lättare är det att missa att grunden är fel.
Grunden är en kort uppdragsbeskrivning. Den svarar på vad kunden vill få gjort, varför, och inom vilka ramar. Den är inte till för att sälja. Den är till för att ni ska vara överens om vad ni pratar om, innan du lägger tid på resten.
Utan anteckningar blir det en efterhandskonstruktion
En uppdragsbeskrivning är aldrig bättre än det den bygger på. Skriver du den ur minnet fyller du luckorna med det du tror. Det gör AI:n också, om du ber den skriva utan underlag.
Därför börjar vi med mötet. Stenografen är byggd för det: en bot deltar i mötet i Teams, Google Meet eller Zoom, och protokollet är klart direkt efter mötet. Det är det protokollet uppdragsbeskrivningen bygger på. Har kunden sagt “vi har inte bestämt budget än” står det där, och då kan det inte bli “budget cirka 200 000” i ett utkast två dagar senare.
Du behöver inte vårt verktyg för att göra så här. Det viktiga är att det finns anteckningar från mötet, gjorda under mötet. Ska du spela in: fråga först.
Samma fält varje gång
Den största lärdomen för oss är tråkig: en bra uppdragsbeskrivning har samma fält varje gång.
Det låter byråkratiskt, men det är fälten som avslöjar luckorna. Har du ingen tidsram att skriva in vet du vad du ska fråga om. Med fritext märks det inte att något saknas.
Vi använder samma tanke i chatten på byki.ai. Den ställer en fråga i taget: vad besökaren vill få gjort och varför, vilket företag och vilken roll, tidsram och budgetram. Budgeten väljs i fasta intervall, och det går bra att svara “osäkert”. Sist kommer namn och e-post.
Två saker har vi bestämt med flit. Chatten lovar aldrig pris eller leveranstid. Det tas i ett samtal, när vi vet tillräckligt. Och innan något skickas ser besökaren en sammanfattning av sina svar och bekräftar den själv.
Låt kunden godkänna
Det sista steget är det viktigaste, och det som oftast hoppas över. Skicka uppdragsbeskrivningen till kunden och be om ett ja, eller rättelser.
Det tar kunden några minuter. Det sparar dig från att skriva en offert på fel uppdrag. Och när offerten väl kommer känner kunden igen sig, eftersom den bygger på något de redan har läst och sagt ja till.
Ett “ja, det stämmer” i ett mejl räcker. Skriv in datumet i beskrivningen.
En mall att börja med
Här är en mall du kan kopiera. Fyll i den efter mötet, med protokollet bredvid.
# Uppdragsbeskrivning: [kund, kort namn på uppdraget]
## Uppdraget i en mening
Vad kunden vill få gjort, med kundens egna ord om det går.
## Varför
Vad händer i dag som inte fungerar? Vad händer om inget görs?
## Kund och kontakt
Företag, kontaktperson, roll. Vem fattar beslutet?
## Ingår
Det som ska levereras.
## Ingår inte
Det ni har pratat om men som ligger utanför, eller som tas senare.
## Tidsram
När behöver kunden det? Fast datum eller önskemål? "Osäkert" är ett svar.
## Budgetram
Ett intervall, eller "osäkert". Inte ditt pris, utan kundens ram.
## Klart när
Hur ser kunden att det blev bra? Något som går att pröva.
## Öppna frågor
Det ni inte vet än, och vem som ska svara.
## Godkänd av kunden
Datum och hur (mejl, samtal).
Två fält gör mest nytta. Ingår inte förebygger de flesta diskussioner längre fram. Öppna frågor gör att du slipper gissa, för det du inte vet får ett eget ställe i stället för att smyga in som ett antagande.
Låt AI:n göra första utkastet
Med ett protokoll och mallen kan AI:n göra grovjobbet. Det viktiga är att den inte får fylla i det som saknas.
Här är protokollet från ett kundmöte och en mall för en uppdragsbeskrivning.
Fyll i mallen bara med det som står i protokollet. Hitta inte på siffror,
datum eller namn. Där protokollet inte säger något: skriv "Saknas" i fältet
och lägg en fråga under "Öppna frågor".
Föreslå inget pris och ingen leveranstid.
[klistra in protokollet]
[klistra in mallen]
Läs sedan utkastet mot protokollet. Allt som inte går att hitta där ska bort eller bli en fråga.
Tänk också på vad du klistrar in var. Ett kundmöte innehåller ofta saker kunden inte vill se i en tjänst du inte har koll på villkoren för.
Det här gör du i morgon
- Ta ditt senaste kundmöte och fyll i mallen. Se hur många fält som blir “Saknas”.
- Skicka de öppna frågorna till kunden, tillsammans med beskrivningen.
- Skriv offerten först när kunden har sagt ja.
Ligger dina kunder i HubSpot kan uppdragsbeskrivningen hamna där också, i stället för i en mapp ingen hittar. Det är den sortens koppling vi bygger inom M365, HubSpot och integrationer, så att ingen för över uppgifterna för hand.