Säljdirektörer använder den här för att omvandla discovery-anteckningar till en offert som ekonomi kan godkänna, eftersom den tvingar fram en prissättningstabell, en tidsplan och en ROI-berättelse på ett ställe. Byråägare använder den när de behöver en konsekvent offertstruktur för många kundtyper utan att det låter mallat. Solution consultants gynnas av att utrullningsplanen tydliggör faser, ansvar och beroenden, vilket minskar leveransrisk. RevOps eller proposal managers använder den för att standardisera vad som är ”bra” (nyttobullets, kostnadstotaler, antaganden), så att granskningar går snabbare.

B2B SaaS-team använder den för att motivera prenumerationskostnad med värdedrivare som tidsbesparing, minskat verktygssprawl eller bättre konvertering genom tratten. Företag inom professionella tjänster (konsult, marknadsföring, IT-tjänster) använder den för att visa ett fasindelat upplägg med tydliga ansvarsområden, vilket hjälper köpare att jämföra leverantörer på lika villkor. E-handel och retail gynnas när förslag handlar om förbättringar i kundresan, eftersom utrullningsplanen kan koppla milstolpar till touchpoints efter köp och operativ beredskap. Vård och reglerade sektorer får värde när offerten måste vara övertygande men försiktig, genom att använda antaganden och alternativ i stället för riskabla löften.

En typisk prompt som ”Skriv ett affärsförslag för mina tjänster” misslyckas eftersom den: saknar en obligatorisk leveransstruktur, så kritiska delar som prissummor och utrullningsmilstolpar hoppas över; inte har någon begränsning som ”exakt 3 nyttobullets”, vilket ger fluffiga, repetitiva sammanfattningar; ignorerar kundspecifik kontext och beroenden, så implementeringen känns orealistisk; producerar generisk ROI-text i stället för värdedrivare med antaganden och tidslinjer; och missar disciplinen att märka saknade detaljer som antaganden, vilket är det som håller offerten trovärdig vid granskning.

Ja, men anpassningen sker i underlaget du klistrar in innan du kör den, eftersom prompten saknar inbyggda variabler. Justera kundkontexten (bransch, nuläge, smärtpunkter), lösningens scope (vad som ingår och vad som uttryckligen exkluderas) samt siffrorna som driver ROI (basvolym, kostnader, konvertering, tid per uppgift). Om detaljer saknas, ange ett intervall och be prompten presentera alternativ med tydligt märkta antaganden. En användbar följdfråga är: ”Skriv om offerten för en CFO-målgrupp; behåll samma struktur, men gör ROI och riskhantering mer framträdande och tona ned implementeringsdetaljer.”

Det största misstaget är att lämna kundsituationen för vag — i stället för ”medelstort bolag som behöver hjälp”, skriv ”Series B SaaS, 40 personer i säljteamet, byter från HubSpot till Salesforce inom 90 dagar, churn ökar i SMB-segmentet”. Ett annat vanligt fel är att utelämna scope-gränser; ”Vi förbättrar onboarding” är svagt, medan ”Fas 1 omfattar onboardingmejl och in-app-checklistor; ingen produktredesign” förebygger missförstånd. Många hoppar också över ROI-underlag och tvingar modellen att gissa; ”ROI blir jättebra” blir fluff, men ”minska manuell rapportering med 6 timmar/vecka för 5 chefer” skapar trovärdiga värdedrivare. Slutligen ber många användare inte modellen att märka antaganden, vilket gör att offerten låter överdrivet självsäker i stället för rådgivande.

Den här prompten är inte optimal för affärer där juridiskt språk är huvudleveransen, eftersom den inte är ett avtal, MSA eller SOW. Den passar också dåligt om du behöver en djup teknisk specifikation som primärt artefakt, eftersom strukturen prioriterar utfall, utrullningsplanering och ROI framför ingenjörsdetaljer. Och om du inte alls har tydliggjort ditt kärnerbjudande blir antagandedelen tung och du kan hamna i att iterera grunder i stället för att finslipa en nästan färdig offert. I de fallen: börja med att definiera scope, paket och ramar, och återvänd sedan till den här prompten för att ta fram det kundfärdiga dokumentet.