제품 데모 발표는 고객 과업 하나를 입력부터 쓸 수 있는 결과물까지 따라가야 합니다. 고객이 이루려는 일을 먼저 설명하고, 업무 흐름을 확인할 장면을 보여 주며, 의미 있는 수정 하나를 할 시간을 남기세요. 청중이 요청하지 않은 기능을 두루 소개하기보다 필요한 경로를 짧게 보여 주는 편이 낫습니다.

설명용 슬라이드를 준비한다면 Presenti로 고객의 요구에 맞는 영업 발표 자료를 만들 수 있습니다. 실시간 시연과 슬라이드 설명의 역할은 구분하세요. 슬라이드는 무엇을 볼지 설명하고, 제품은 실제로 무슨 일이 일어나는지 보여 줍니다.

고객의 문제, 처리 흐름, 기대 결과를 연결해 설명하는 발표자
청중은 기능 목록을 외우는 대신 데모에서 과업 하나를 따라갑니다.

고객 과업의 예시

운영 관리자가 업무 절차의 구성안을 짧은 교육 자료로 만들려고 한다고 가정해 보겠습니다. 설명을 위한 이 예시의 원자료는 가상입니다. Northline이라는 회사의 장비 신청 절차를 다루며 실제 직원이나 고객 데이터는 포함하지 않습니다.

관리자는 누가 신청하고, 누가 승인하며, 정보가 부족할 때 어떻게 처리하는지 설명하는 초안을 원합니다. 따라서 데모는 원자료, 슬라이드 구조, 정보 보완을 위한 반려 단계의 수정을 보여 줘야 합니다. 모든 테마, 차트, 공유 설정을 시연할 필요는 없습니다.

대상: Northline의 신입 직원
목적: 장비 신청 절차 설명
1. 품목, 업무상 필요 이유, 필요한 날짜를 적어 신청한다.
2. 팀 관리자가 업무상 필요 이유를 확인한다.
3. IT팀이 제공 가능 여부를 확인한다.
4. 정보가 부족하면 부족한 항목을 명시해 신청을 반려한다.
5. 승인되면 수령 또는 배송 정보를 확인한다.
6. 특수한 신청은 별도로 판단할 수 있도록 서비스 데스크로 전달한다.
정보 보완을 위한 반려와 신청 거절을 구분한다.

원자료에 없는 승인 기한을 만들거나, 사람이 판단한다고만 적힌 단계를 자동화하지 마세요. 그렇게 하면 과업 자체를 바꿔 제품이 더 많은 일을 할 수 있는 것처럼 보이게 됩니다.

12분 데모 진행안

다음 시간표는 결과를 살펴보고 수정할 시간을 남깁니다. 실제로 사용할 계정, 기기, 입력으로 리허설하세요. 언제나 같은 속도라고 주장하기보다 실제 처리 시간에 맞게 일정을 조정합니다.

시간발표자의 행동청중이 판단할 내용
00:00–01:00관리자의 과업을 설명하고 원래 구성안을 보여 준다.익숙한 자료에서 데모가 시작된다.
01:00–03:00제품이 지원하는 텍스트 입력 방식으로 구성안을 넣고 적절한 스타일을 고른다.입력과 디자인 선택이 대상에 맞는다.
03:00–05:00초안을 생성하고 필요하면 대기 상태를 설명한다.실시간 작업과 준비된 결과가 구분된다.
05:00–07:00슬라이드 순서를 살펴보고 정보 보완을 위한 반려 단계를 찾는다.절차의 차이가 구조에 유지된다.
07:00–09:00모호한 “신청 거절” 제목을 “부족한 정보의 보완을 위해 반려”로 바꾼다.초안에서 표현을 고칠 수 있다.
09:00–10:00편집 계속하기나 사용 가능한 내보내기 등 고객이 원하는 다음 단계를 보여 준다.결과물 전달이 고객의 요구에 맞는다.
10:00–12:00과업 관련 질문을 받고 다음에 해 볼 작은 시험에 합의한다.고객이 준비할 것과 남은 검증을 안다.

Presenti의 공개 텍스트 기반 발표 자료 페이지는 주제 또는 붙여 넣은 텍스트 입력, 디자인 선택, 편집 가능한 초안, 검토 후 내보내기를 설명합니다. 현재 계정에서 가능한 경로를 시연하세요. 홍보용 화면만 보고 특정 한도나 권한을 추정하지 마세요.

고객의 의문에 답하는 수정 보여 주기

이 사례에서 가장 중요한 확인 장면은 생성이 아닙니다. 반려된 신청과 거절된 신청의 차이를 찾아 고치는 장면입니다. 수정 전에 “초안에서 이 차이가 불분명하다면 처음부터 다시 만들지 않고 고칠 수 있을까요?”라고 묻습니다. 그런 다음 문구를 수정하고 원래 구성안을 다시 확인하세요.

수정 전후를 읽을 수 있을 만큼 오래 보여 주세요. 수정이 다른 슬라이드도 바꾼다면 그 결과를 확인하고 넘어갑니다. “완전히 편집 가능하다”는 말보다 구체적인 수정 하나가 실제 작업 흐름을 더 잘 보여 줍니다.

공식 Rewrite 메뉴 발췌와 신청 거절을 정보 보완을 위한 반려로 바꾸는 디자인 예시
신청 거절과 정보 보완을 위한 반려를 구분하는 표현의 예시입니다. Rewrite 메뉴는 Presenti 공식 화면에서 발췌했습니다.

실시간 시연이 실패해도 설명은 정직하게 유지하기

대체 파일 3개를 준비합니다. 그대로 사용할 입력, 이전 실행에서 저장한 초안, 수정 장면의 정지 이미지입니다. 초안에는 준비한 날짜를 표시하세요. 생성이 멈추면 “같은 입력으로 미리 준비한 초안입니다”라고 말한 뒤 검토와 편집을 이어갑니다. 저장된 결과가 지금 막 실시간으로 생성된 것처럼 보여서는 안 됩니다. 정지 이미지는 프레젠테이션 스크린샷 가이드에 따라 민감한 정보를 가리고 과업 맥락을 남긴 뒤, 슬라이드 표시 크기에서 읽히는지 확인하세요. 실시간 동작의 증거가 아니라 대체 자료임을 계속 명시해야 합니다.

편집기 자체가 작동하지 않으면 정지 이미지로 확인하려던 내용을 설명하고 실제 동작은 아직 보여 줘야 한다고 기록합니다. 내보내기가 실패하면 고객에게 전달할 파일이 준비됐다고 말하지 말고 후속 확인 항목으로 남깁니다. 대체 절차는 논의를 이어 가기 위한 것이지 모든 단계가 통과했다는 주장이 아닙니다.

고객이 직접 실행할 수 있는 시험으로 마무리하기

운영 관리자에게는 작은 다음 행동 하나를 제안합니다. 민감한 정보가 없는 업무 구성안을 사용하고, 결과 자료를 본 동료에게 절차를 설명해 달라고 하는 것입니다. 동료의 반응으로 순서와 표현이 명확한지 알 수 있습니다. 편집 가능한 PowerPoint 파일이 필요하다면 내보내기 표시만으로 판단하지 말고, 파일을 열고 수정하는 것까지 시험에 포함하세요.

Salesforce의 데모 가이드는 고객 질문에 답하는 맞춤형 체험을 강조합니다. 이 진행안도 같은 목적입니다. 고객 과업을 놓치지 않고 관련 동작을 제품으로 확인하며, 관련 없는 기능은 다른 대화로 미룹니다.

직접 설명하고 확인할 수 있는 짧은 구성안으로 Presenti에서 발표 자료를 시작해 보세요. 가장 화려한 부분이 아니라 고객이 믿을 수 있는지 확인해야 하는 부분을 중심으로 데모를 구성합니다.