Demo Script — polski SaaS B2B

Format demo: live vs. slajdy vs. nagrane

Live product demo (domyślne dla PL micro-SaaS)

• Najwyższy impact, najwyższe ryzyko. Wszystko może się zepsuć.
• Wymaga czystego środowiska demo (zobacz pre-demo checklist)
• Najlepsze dla deali gdzie produkt "sprzedaje się sam" gdy widzą go w akcji

Slide-supported demo

• Gdy demo dla zarządu/CEO którzy nie chcą klikać
• Lead 3-5 slajdami (discovery recap → architektura → approach), potem 1-2 kluczowe workflow live
• Slajdy zawierają outcomes i proof points, NIE feature lists
• Nie czytaj slajdów. To anchor dla Twojej narracji.

Recorded / async demo

• Gdy ktoś nie może być na live, albo "prześlij mi coś żeby podesłać zarządowi"
• 5-8 minut, skupione na ich 2-3 topowych bólach
• Narracja jak na live, nie marketing video
• Użyj ich nazwy firmy i konkretnej sytuacji
• Wyślij przez trackable link (Loom) — zobaczysz czy obejrzeli i jak daleko
• Follow-up gdy obejrzą: "Widziałem że przejrzałeś walkthrough — co Cię najbardziej interesuje?"

Pre-demo checklist — środowisko

• Demo environment wstał i działa. Test 1h przed rozmową, nie 1 min.
• Sample data realistyczne i istotne. Healthcare? Nie pokazuj retail dane.
• Jeśli załadowałeś ich dane (pilot, sandbox) — sprawdź czy się załadowały. Brakujące dane mid-demo = śmierć credibility.
• Integracje które pokazujesz są podłączone i działają
• Twoje konto ma właściwe permissions. Nic gorszego niż "hmm, zwykle nie widzę tego błędu"
• Usuń test labels, dummy użytkowników "Test User", wszystko co wygląda half-baked
• Motyw/view najbardziej profesjonalny
• Wyłącz powiadomienia (Focus Mode na Mac, Focus Assist Windows). Żadne Slacki, maile, polskie SMS-y
• Zamknij karty i aplikacje których nie potrzebujesz. Incognito window z tylko potrzebnymi kartami.
• Wyczyść history bar przeglądarki jeśli pokazuje często odwiedzane
• Backup screenshots folder na pulpicie — każdy kluczowy workflow jako statyczny obraz na wypadek awarii

Demo structure: story arc (20-30 min)

Akt 1: Setup (5 min)

Recap discovery. Udowodnij że słuchałeś.

"Zanim cokolwiek pokażę, chcę się upewnić że dobrze zrozumiałem.
Powiedziałeś że {{pain 1}}, co powoduje {{impact}}. Obecnie {{current
process}}, i to Wam {{consequence}}. A gdybyście mogli {{desired
outcome}}, to dla Was byłoby {{value}}. Dobrze zrozumiałem? Czegoś
brakuje?"

To robi 3 rzeczy: potwierdza że słuchałeś, re-aktywuje ich ból, sprawia że kiwają głowami ZANIM pokażesz pierwszy screen.

Ustaw agendę:

"Pokażę Ci dziś trzy rzeczy:
1. Jak rozwiązujemy {{pain 1}}
2. Jak obsługujemy {{pain 2}}
3. Jak firmy jak Wasza zwykle dostają wyniki w {{timeframe}}
Potem porozmawiamy o następnych krokach. Brzmi dobrze?"

Akt 2: Demonstration (15-20 min)

Dla każdego pain pointu — ten pattern:

1. Przypomnij ból (10 sek) "Wspominałeś że Twój zespół traci 6h tygodniowo na ręczne {{task}}."

2. Pokaż rozwiązanie (2-3 min) Przejdź przez konkretny workflow który eliminuje ten ból. Narracja. Ich język, nie Twoje nazwy features.

3. Połącz z outcome (30 sek) "Więc zamiast 6h ręcznej pracy, to zajmuje ok 15 min. Dla zespołu 8 osób to ~45h miesięcznie z powrotem."

4. Wrzuć proof point (15 sek) "{{Klient}} z {{podobna branża}} widział dokładnie to — skrócili ten proces z całego dnia do mniej niż godziny."

5. Check-in (10 sek) "Czy to pasuje do tego z czym się mierzycie? Zadziałałoby w Waszym środowisku?"

Powtórz dla każdego pain pointu. 3 pain points = 3 cycles.

Akt 3: Proof & close (5 min)

Social proof: 1-2 case studies z polskiego rynku (albo similar-size fit).

Summary:

"Podsumowując — pokazaliśmy jak {{produkt}} rozwiązuje {{pain 1}}
przez {{outcome 1}}, obsługuje {{pain 2}} przez {{outcome 2}}, i daje
{{outcome 3}}. Z tego co mówiłeś brzmi że {{pain 1}} jest największym
priorytetem. Dobrze?"

Next step: Zaproponuj konkretną akcję.

"Następny krok dla większości firm na tym etapie to {{propozycja/
technical deep-dive/pilot/spotkanie z CEO}}. Umawiamy to w kalendarzu?"

Feature-to-outcome mapping (ZAWSZE przed demo)

Nigdy nie pokazuj feature bez wypełnionego wiersza.

Jeśli nie możesz wypełnić kolumny "Ich ból" dla feature'a — nie pokazuj go.

Disaster recovery

Rzeczy się psują podczas demo. Pytanie nie czy tylko jak odzyskasz.

Feature crashuje / nie ładuje się

• Nie panikuj. Nie przepraszaj za dużo. Jedno spokojne zdanie: "Wygląda że dziś jest wolne. Pokażę to w inny sposób."
• Miej backup screenshots albo nagranie każdego kluczowego workflow. Folder na pulpicie, gotowy do share.
• Jeśli feature jest krytyczny i zepsuty, nie forsuj: "Ten feature akurat najbardziej oszczędza czas zespołu — chcę żebyś zobaczył go działającego. Wyślę Ci nagranie zaraz po rozmowie."
• Zamień na trust moment: "Wolę żebyś zobaczył to działające niż żebym troubleshoot'ował na żywo. Nie marnuję Twojego czasu."

Integracja failuje

• Jeśli integracja miała pullować dane z ich systemu i nie działa: "Połączenie czka. Pokażę to na naszych sample data — workflow jest identyczny, tylko patrzymy na inne liczby."
• Miej pre-loaded result gotowy. Jeśli integracja miała pullować CRM dane — miej screenshot jak to wygląda gdy działa.

Video/audio/screen share problems

• Backup screen share: Zoom → Google Meet, lub odwrotnie
• Choppy video: "Wyłączam kamerę żeby poprawić quality — żeby demo przeszło czysto."
• Awaria audio: zawsze miej numer prospecta. Zadzwoń i narraj podczas gdy oglądają screen share.

Prospect pyta o coś co jest zepsute

• Known issue: "Wiemy o tym, fix planowany w {{konkretny timeframe}}. Obecnie klienci obsługują to tak..."
• Nowe: "Nie widziałem tego wcześniej — nasz technical team odezwie się z konkretami. Odpowiem Ci do {{konkretna pora}}."
• Nigdy nie mów "to nie powinno się stać". Stało się. Zobaczyli.

Recording i follow-up

Czy nagrywać demo?

Zwykle tak. Zawsze pytaj: "Czy mógłbym to nagrać, żeby móc udostępnić komuś z zespołu kto nie mógł być na rozmowie?"

Benefity:

• Champion może share'ować wewnętrznie z ludźmi których nie widziałeś
• Możesz review'ować własne demo performance
• Tworzy asset zamiast "możemy zrobić jeszcze jedno demo dla naszego CEO?"

Nie nagrywaj jeśli: powiedzą nie (nie pushuj), pokazujesz ich poufne dane, demo idzie źle i nie chcesz dowodów.

Post-demo follow-up email (w ciągu 2h)

1. Co pokazałeś — 3-4 buletki, outcome-focused (nie "pokazałem dashboard feature" tylko "jak {{produkt}} daje real-time visibility w pipeline, eliminując 6h/mies ręcznego raportowania")
2. Co powiedzieli — kluczowe reakcje, concerns, pytania które parknąłeś. W ich słowach.
3. Next step — konkretna akcja, data, uczestnicy
4. Recording link — jeśli nagrałeś
5. Highlight reel — jeśli demo było >30 min, rozważ 3-5 min clip z 3 kluczowymi momentami. To champion faktycznie forward'uje do szefa.

Multi-stakeholder demos (rzadkie w PL micro-SaaS, ale wartościowe)

Executive + practitioner w jednym pokoju

• Lead z business outcomes (executive to słyszy)
• Pokaż wystarczająco produktu by usatysfakcjonować practitionera
• Flaguj ease of implementation — executives martwią się disruption, practitioners learning curve
• Adresuj executive'a po imieniu gdy pokazujesz ROI. Adresuj practitioner gdy pokazujesz workflow.

Technical evaluator

• Głębiej na architecture, integracje, security, data handling
• Pomiń business case — już wiedzą czemu ewaluują
• Bądź szczery o limitations. Technical ludzie szanują "nie robimy tego" bardziej niż "pewnie moglibyśmy"
• Miej gotowe odpowiedzi na: API access, data export, SSO, uptime SLA, compliance (RODO, ISO)

Executive-only demo

• Cut product walkthrough o 50%
• Double proof points i ROI discussion
• Pokaż dashboards i raporty, nie workflow details
• Skup się na: time to value, przewaga konkurencyjna, redukcja ryzyka, efektywność zespołu
• Pod 20 min jeśli możliwe.
• Executives przerwą strategic questions. Witaj je — są zaangażowani. Executive który siedzi cicho przez 30 min jest znudzony albo już zdecydował nie.
• Zakończ jasnym decision question: "Na podstawie tego co widziałeś — warto to pociągnąć dalej?" Executive szanują bezpośredniość.

Competitive positioning podczas demo

Zasady:

1. Nigdy nie trash'uj konkurenta po nazwisku bez powodu. Wyglądasz na niepewnego.
2. Gdy oni sami wspomną konkurenta, acknowledge + pivot. "Są solidni w {{X}}. Gdzie jesteśmy inni to {{Y}}, co ma znaczenie kiedy {{ich specyficzna sytuacja}}."
3. Stawiaj pułapki pytaniami. Przed pokazaniem differentiating feature zapytaj: "Jak ważne dla Waszego zespołu jest {{capability}}?" Gdy powiedzą że ważne — pokaż. Nieobecność tej funkcji u konkurenta staje się oczywista bez Twojego komentarza.
4. Używaj switchover stories. "Mamy 15 klientów którzy przeszli z {{konkurent}}. Najczęściej mówią {{insight}}." Bardziej wiarygodne niż feature comparison.

Obsługa pytań mid-demo

Odpowiadaj od razu jeśli:

• Bezpośrednio dotyczy tego co pokazujesz
• Pytający to najbardziej senior osoba w pokoju
• To deal-breaker (cena, integracja, bezpieczeństwo)

Park for later jeśli:

• Dotyczy feature'a który planujesz pokazać za 5 min
• Skasowałoby narrację dla innych stakeholderów
• Deep technical w executive demo

Jak parkować z gracją: "Dobre pytanie. Akurat pokrywam to za ok 5 min kiedy pokażę {{sekcja}}. Mogę do tego wrócić? Chcę dać temu pełny kontekst."

Napisz to widocznie (shared notes albo notepad). Wróć do tego. Jeśli zapomnisz — oni nie.

Najczęstsze błędy

• Feature tour. Pokazywanie wszystkiego zamiast tego co ma znaczenie. Śmierć przez tysiąc features.
• Brak discovery recap. Skoczenie prosto w produkt. Audience nie wie czemu ma dbać.
• Ignorowanie pytania. Każde deferowanie do "follow-upu" sygnalizuje że nie znasz własnego produktu.
• Demo tylko happy path. Tylko perfect scenario. Mądrzy kupujący pytają "co się dzieje jak X idzie źle?"
• Running over time. Jesteś 25 min w 30-minutowym demo → stop i close. Potrzebujesz czasu na next steps.
• Nie check-in. 15 min bez ani jednego pytania. Straciłeś ich.
• Brudne środowisko. Polskie powiadomienia Slack, test data z imionami "Janek Testowy", personal bookmarks widoczne.
• Brak disaster recovery. Feature się psuje → zamarzasz. Zawsze miej fallback.
• Kończenie bez next step. "Dzięki, wyślę info" to NIE close. Zaproponuj coś konkretnego.

Output format

Budując demo script, dostarcz:

1. Demo brief — prospect context, stakeholderzy, czas, discovery pain points
2. Feature-to-outcome map — wypełniona tabela
3. Scripted opening — discovery recap + agenda (customized)
4. Demo flow — scene-by-scene walkthrough z talking points, transitions, check-in questions
5. Competitive positioning notes — jeśli konkurenci w grze
6. Closing script — summary + next step ask
7. Parking lot prep — prawdopodobne pytania i czy odpowiedzieć czy parkować
8. Disaster recovery plan — backup screenshots/recordings dla każdego pokazywanego feature'a live
9. Follow-up email draft — post-demo recap template z polami pre-filled z discovery

Powiązane skille

• craig-call-debrief-pl — review notatek z discovery PRZED demo
• sales-context — value prop + differentiators
• craig-proposal-pricing-pl — najczęstszy next step po udanym demo
• discovery-call (natywny PL) — dobra discovery = dobre demo
• craig-pipeline-review-pl — deal post-demo aktualizacja w pipeline

Credit: Zaadaptowane z TheCraigHewitt/skills/demo-script (~400 linii → ~215 linii, kompresja 46%). Wycięto: competitive bake-off 60 min enterprise demos, checklist-driven RFP demos dla procurement, multi-stakeholder 5+ pokoje, US Vidyard/Loom pricing. Dodano: polski realizm 20-30 min demo dla micro-SaaS, founder sprzedaje sam (jeden punkt uwagi), polskie pre-demo checklist (wyłącz polskie powiadomienia Slack/SMS), polski language patterns recapu z "kiwają głowami".