← Quay lại Blog

Mẫu kịch bản demo sản phẩm SaaS (3 phút): Sao chép/Dán + Ví dụ

Published

Những người sáng lập thường tự phá hỏng demo sản phẩm của chính mình.

Họ xây một công cụ SaaS tuyệt vời, và khi đến lúc demo, họ dành mười hai phút khổ sở click qua từng nút cài đặt và menu tích hợp.

Khách hàng tiềm năng không quan tâm trang cài đặt của bạn. Họ muốn biết một điều: “Phần mềm này có thể gỡ nỗi đau của tôi ngay bây giờ không?”

Bạn cần một demo ba phút tập trung trả lời ngay điều đó. Đây là kịch bản.

Nếu giao diện giữ sắc nét và camera tracking tự động (đúng thứ AUFZEICHNA làm), kiểu demo này chuyển đổi đều đặn. Xem bản demo · Giá trọn đời


Cấu trúc 3 phút

Đi theo timeline này. Đừng đi chệch.

0:00-0:15 Câu móc 0:15-0:45 Vấn đề 0:45-1:45 “Khoảnh khắc kỳ diệu” 1:45-2:30 Bằng chứng 2:30-3:00 Một lời kêu gọi hành động


Kịch bản mặc định

Điều chỉnh các chỗ trống cho sản phẩm của bạn.

0:00-0:15, câu móc

“Nếu bạn là [đối tượng mục tiêu] và chán ngấy [nỗi đau cụ thể], hãy xem cái này. Trong ba phút tới tôi sẽ cho bạn thấy [sản phẩm] mang lại [kết quả] cho bạn mà không cần [trở ngại lớn].”

0:15-0:45, nỗi đau

“Hiện tại, hầu hết đội ngũ làm việc này bằng [công cụ cũ hoặc bảng tính]. Nghĩa là:

  • [Nỗi đau A]
  • [Nỗi đau B]
  • [Nỗi đau C]

Và ma sát đó tốn của bạn [thời gian/tiền bạc].”

0:45-1:45, khoảnh khắc kỳ diệu

“Đây rồi, bên trong [sản phẩm]. Xem này: tôi làm [hành động cốt lõi]. Nó xử lý [hành động kỳ diệu]. Và đây là kết quả: [sự biến đổi].

Nó hoạt động vì bạn không bao giờ phải động vào [bước cũ khó chịu] nữa.”

1:45-2:30, bằng chứng

“Trong môi trường thật, quy trình trông như thế này:

  1. Bạn kích hoạt [bước một].
  2. Nó xử lý [bước hai].
  3. Bạn giao [bước ba].

Điều đó đòi lại [chỉ số cụ thể]. Và nếu muốn thử trên dữ liệu của mình, bạn có thể đạt được chừng này trong [thời gian đạt giá trị].”

2:30-3:00, lời kêu gọi hành động

“Nếu bạn cần [kết quả], hãy thử [sản phẩm]. Bản dùng thử miễn phí ở link bên dưới. Có gì chưa rõ, trả lời trực tiếp.”


Biến thể theo khán giả

Dành cho kỹ sư và DevOps

Câu móc: “Nếu bạn quản lý hạ tầng và muốn gỡ [nỗi đau], đây là con đường nhanh nhất tới [kết quả].” Thực hiện: Bỏ ngôn ngữ marketing. Cho thấy payload API, xác minh webhook, chạy lệnh terminal. Đừng đọc to tài liệu.

Dành cho người sáng lập và marketing

Câu móc: “Nếu bạn muốn [kết quả] mà không cần thuê kỹ sư hay học một nền tảng nặng…” Thực hiện: Tập trung vào sự đơn giản của giao diện. Ít click hơn, trước/sau rõ ràng. Đừng cho thấy menu cấu hình.

Dành cho người mua hoài nghi

Câu móc: “Đây không phải AI thần kỳ. Nó chỉ gỡ [nút thắt cụ thể].” Thực hiện: Nêu giới hạn ngay từ đầu. “Đây là điều công cụ này không làm được.” Thừa nhận giới hạn tạo niềm tin và khiến phần còn lại của demo đáng tin hơn.


Danh sách kiểm tra trình bày

Một kịch bản hoàn hảo thất bại nếu phần trình bày trông hỗn loạn.

  • Phóng to chữ. Mọi giá trị phải đọc được trên màn hình điện thoại.
  • Lấy nét khung hình. Auto-zoom vào khoảnh khắc kỳ diệu để người xem không phải đi tìm con trỏ.
  • Cắt khoảng chết. Gỡ trạng thái tải và lúc chờ npm install.
  • Bám trọng tâm. Một quy trình, trình bày tốt.

Để tự động hóa lấy nét và trình bày trên Windows: Quy trình screencast điện ảnh


Câu hỏi thường gặp

Vì sao không làm demo mười phút bao phủ mọi tính năng? Vì khách truy cập lạnh sẽ bỏ đi. Họ không quan tâm danh sách tính năng của bạn; họ quan tâm phần lõi có giải quyết vấn đề của họ nhanh không.

Người sáng lập có nên tự quay demo không? Có. Demo do người sáng lập tự dẫn, trực tiếp và hơi chưa hoàn hảo, có cảm giác thật hơn một lời lồng tiếng công ty vô hồn, và hiệu quả hơn.

Làm sao giữ người xem khỏi lạc trong giao diện? Độ rõ hình ảnh: phông to, auto-zoom vào vùng đang hoạt động và không có chuyển động chuột rung lắc.


Có liên quan

Related workflows