고객 요청서를 컨설팅 발표 자료로 만들 때는 먼저 확인된 조건과 더 알아봐야 할 내용을 구분하세요. 그다음 업무 범위에 영향을 주는 요구 간 충돌을 보여주고, 실제로 다른 두 가지 접근법을 비교합니다. 산출물과 날짜를 나열하기 전에, 신뢰할 수 있는 제안에 필요한 결정을 고객에게 요청하는 순서입니다.
프로젝트를 논의하기 전에 회사 소개가 필요하다면, 9장으로 구성한 회사 소개 발표 예시를 참고해 서비스, 관련 사례, 담당 역할, 다음 논의를 구체적인 제안과 구분할 수 있습니다.
여기서 만드는 것은 최종 제안서가 아니라 업무 범위를 협의하는 발표 자료입니다. 고객과 컨설턴트가 이번 업무에 무엇을 포함할지 합의하는 것이 목적입니다. 방향이 정해지면 Presenti의 영업 제안 자료 만들기를 활용해 다음 대화에 쓸 편집 가능한 초안을 준비할 수 있습니다. 아래 사례는 가상으로 구성했습니다. 원래 요청과 아직 답을 얻지 못한 질문을 끝까지 연결해서 살펴봅니다.
키워드보다 어떤 약속이 되는지 먼저 읽기
한 유통업체가 다음과 같은 요청을 보냈다고 가정해 보겠습니다.
“견적서 작성에 너무 오래 걸립니다. CRM을 교체하지 않고 6주 안에 3개국 팀의 업무 절차를 통일하고 싶습니다. 영업팀은 요청 정보가 부족해서 그렇다고 하고, 운영팀은 승인이 지연되는 것이 문제라고 합니다. 신뢰할 만한 현재 측정값은 없습니다. 담당자는 일주일에 한 번, 30분 회의에만 참석할 수 있습니다.”
이를 “6주 안에 3개국 견적 업무 효율화”로 요약하면 단정적인 발표 자료가 됩니다. 하지만 희망 일정이 납품 약속으로 바뀌고, 서로 다른 두 설명이 이미 확인된 진단처럼 취급됩니다.
요청서를 두 번 읽으세요. 처음에는 원하는 결과와 제약을 추립니다. 두 번째에는 답이 달라질 경우 방법, 투입 공수, 약속이 바뀌는 부분을 표시합니다. 해석 옆에 고객의 원문을 남겨두면 어느 지점에서 판단이나 가정이 들어갔는지 알 수 있습니다.
조건, 목표, 미확인 사항 구분하기
| 요청서 내용 | 해석 | 슬라이드에 담을 내용 |
|---|---|---|
| CRM을 교체하지 않음 | 명시된 제약 | 기존 시스템 안에서 진행하고, 설정 변경을 승인할 사람을 확인합니다. |
| 3개국 팀의 절차 통일 | 원하는 결과이지, 합의된 범위는 아님 | 공통으로 맞출 단계와 각국에 남겨둘 단계를 묻습니다. |
| 6주 | 요청한 기간 | 권고안 제출, 시범 운영 완료, 전면 도입 중 어디까지인지 확인합니다. |
| 정보 부족 또는 승인 지연 | 조사할 두 가지 설명 | 둘 다 제시하고, 구체적인 사례 없이 원인을 정하지 않습니다. |
| 믿을 만한 현재 측정값이 없음 | 부족한 자료 | 시간 기록과 승인 단계가 있는 최근 견적 사례 몇 건을 요청합니다. |
하나의 단어가 여러 뜻으로 쓰일 때 이 구분은 특히 중요합니다. “표준화”가 입력 항목 통일인지, 승인 규칙 통일인지, 국가별 전체 절차를 똑같이 만드는 것인지 적어보세요. 모호함을 감춘 자신감 있는 슬라이드보다 구체적인 확인 질문이 도움이 됩니다.
범위 충돌을 이야기의 중심에 놓기
이 사례의 어려움은 3개 팀, 6주, 제한된 참여 시간, 현재 측정값 부재가 겹친다는 데 있습니다. 고객이 무리한 요구를 한다고 지적하는 슬라이드를 만들 필요는 없습니다. 실행 가능한 업무로 만들려면 어떤 조건이 바뀌어야 하는지 보여주세요.
제목은 “작업 계획을 고르기 전에 6주 후의 도착점을 정합니다”처럼 쓸 수 있습니다. 아래에는 진단, 시범 운영, 전면 도입이라는 세 가지 도착점을 가로로 배치합니다. 단순한 순서도면 충분합니다. 고객이 실제로 원하는 도착점을 표시하고 나머지는 후속 업무로 분리하세요. 세 가지를 하나의 약속에 모두 넣지 않는 것이 핵심입니다.
이어서 결정에 영향을 주는 질문을 던집니다. “시범 운영 완료가 우선이라면, 한 국가 팀에서 사례와 검토 담당자를 제공할 수 있나요?” 이렇게 해야 필요한 협조와 선택지가 연결됩니다. “정보를 더 주실 수 있나요?”라는 질문만으로는 그 관계가 드러나지 않습니다.
서로 다른 불확실성을 줄이는 두 접근법 비교하기
이름만 다르고 내용은 비슷한 세 가지 패키지를 제시하지 마세요. 이 요청서에는 다음 두 경로가 의미 있습니다.
- 진단부터 진행: 세 팀의 최근 견적 처리 과정을 살펴보고, 주요 지연 구간을 합의한 뒤 공통 절차를 제안합니다. 산출물은 권고안과 우선순위를 정한 변경 목록입니다. 이미 현장에 도입된 운영 체계가 아닙니다.
- 한 팀에서 시범 운영: 한 국가 팀을 선정해 견적 절차의 제한된 변경을 시험하고, 결과를 바탕으로 확대 범위를 결정합니다. 사례에 접근할 수 있어야 하고 검토 담당자도 필요합니다. 같은 변경이 세 팀 모두에 적합하다는 사실까지 입증하는 것은 아닙니다.
필요한 자료 접근, 참여 인력, 구체적인 산출물, 남는 질문을 기준으로 비교하세요. 고객과 평가 기준 및 점수의 의미를 합의하지 않았다면 숫자로 점수를 매기지 않습니다. 공수를 추정하기에도 정보가 부족하다면 비용 제안은 다음 단계로 남깁니다. 대안이 서로 비교 가능하고 기준도 합의되었다면 가중치 의사결정 매트릭스로 장단점과 우선순위 변화에 따른 선택의 차이를 보여 줄 수 있습니다.
고객이 받는 결과와 각 경로에서 남는 질문 보여 주기
앞서 나온 유통업체의 요청서는 다음처럼 비교할 수 있습니다. 논의를 위한 범위 제안이며, 납품 약속이나 견적은 아닙니다.
| 비교 항목 | 진단부터 진행 | 한 팀에서 시범 운영 |
|---|---|---|
| 답할 질문 | 세 팀의 견적 요청은 어디에서 대기하며, 그 이유는 무엇일 수 있나요? | 정해진 변경 하나가 선정한 팀의 일상 업무에서 작동할 수 있나요? |
| 고객이 제공할 사항 | 국가별로 비교 가능한 최근 사례와 시간 기록의 의미를 설명할 사람. | 한 팀의 합의된 사례, 현지 검토 담당자, 선정한 변경을 시험할 권한. |
| 제안하는 산출물 | 업무 절차 비교 문서, 근거가 부족한 부분, 변경 후보. | 범위가 정해진 시험, 관찰 결과, 다음 시험 또는 확대 적용에 대한 권고. |
| 포함하지 않는 일 | 선호하는 변경안을 실제 도입하거나 성과 개선을 입증하는 일. | 세 팀 전체로 확대하거나 현지 결과를 다른 팀에도 일반화할 수 있다고 입증하는 일. |
| 견적 작성이 어려운 조건 | 기록 접근이 불확실하거나 견적 업무의 시작·종료 시점이 서로 다른 뜻으로 쓰이는 경우. | 검토 담당자가 없거나, 시험 권한이 없거나, 결과를 관찰할 현실적인 방법이 없는 경우. |
6주라는 요청 기간은 표 위에 그대로 표시합니다. 기한 때문에 의존 조건을 감추어서는 안 됩니다. 고객이 주 1회 30분 회의에만 참석할 수 있다면 회의 밖에서 누가 기록을 준비할지, 의사결정에 얼마나 걸릴지 물어보세요. 6회의 주간 회의는 회의 시간으로 3시간입니다. 고객이나 컨설턴트가 업무 전체에 투입할 수 있는 공수를 뜻하지는 않습니다.
미결정 사항을 중심으로 여섯 장 구성하기
| 슬라이드 | 제목 예시 | 보여줄 내용 |
|---|---|---|
| 1 | “6주 안에 완료”는 어디까지인가요? | 이번에 내릴 결정과 세 가지 도착점. |
| 2 | 시스템 조건은 정해졌지만 해결책은 아직입니다 | 확정된 제약과 미확인 요구를 나란히 배치. |
| 3 | 두 설명에는 서로 다른 자료가 필요합니다 | 정보 부족과 승인 지연 가설, 각각에 필요한 사례 요청. |
| 4 | 진단부터 할까요, 한 팀에서 시험할까요? | 두 경로의 산출물, 의존 조건, 한계. |
| 5 | 시범 운영은 3개국 전면 도입이 아닙니다 | 포함할 업무, 제외할 업무, 고객이 제공할 사항. |
| 6 | 경로, 검토 담당자, 제공 가능한 사례를 정합니다 | 업무 범위와 견적을 작성하기 전에 필요한 세 가지 답변. |
요청서 전문은 부록이나 첨부 문서에 둡니다. 본문에서는 선택의 이유를 설명하는 문구만 반복하세요. 짧은 원문 옆에 해석을 붙이면 고객이 요청서를 전부 다시 읽지 않아도 서로 다르게 이해한 부분을 찾을 수 있습니다.
AI에도 모호한 부분을 그대로 전달하기
조직 규정에 따라 사용할 수 있는 형태로 요청서를 정리합니다. 논의에 불필요한 기밀 이름이나 개별 사례 정보는 제거하세요. 그다음 초안 도구에 구체적으로 요청합니다.
가상의 유통업체를 위한 업무 범위 협의용 발표 자료를 여섯 장으로 만들어 주세요. 고객은 CRM을 바꾸지 않고 6주 안에 3개국 팀의 견적 절차를 통일하려고 합니다. 회의는 주 1회 30분만 가능합니다. 영업팀은 요청 정보 부족을, 운영팀은 승인 지연을 원인으로 추정합니다. 신뢰할 만한 현재 측정값은 없습니다. 확정 조건, 가설, 미해결 질문을 구분하세요. 먼저 진단하는 방법과 한 팀에서 시범 운영하는 방법을 비교하세요. 비용, 절감 효과, 날짜, 사례 근거, 우선할 원인을 만들어내지 마세요. 6주는 요청 기간이며 확정된 납품 약속이 아닙니다. 마지막에는 경로, 고객 측 검토 담당자, 사례 접근에 관한 결정을 요청하세요.
시각 디자인에 시간을 쓰기 전에 개요부터 읽습니다. “견적 작성 시간 40% 단축” 같은 제목이 생성되면, 요청서로 뒷받침할 수 있는 “변경안을 고르기 전에 견적을 지연시키는 단계를 찾습니다”로 바꾸세요. 전자는 결과를 지어내지만 후자는 회의에 목적을 줍니다.
논의 후 작성하는 업무 범위 메모 예시
고객이 한 국가 팀의 시범 운영을 선택하고, 익명화한 최근 사례를 제공하기로 했다고 가정해 보겠습니다. 마지막 슬라이드에는 다음처럼 짧은 범위 메모를 담을 수 있습니다.
제안 업무: 선정한 팀의 현재 견적 처리 단계를 문서화하고, 시험할 변경 하나를 합의한 뒤, 지정된 검토 담당자와 관찰 결과를 살펴봅니다. 고객은 적절한 사례 기록에 접근할 수 있는지와 누가 시험을 승인할 수 있는지 확인합니다. 산출물은 시범 운영 결과와 권고안이며, 3개국 전면 도입이 아닙니다. 기록 접근, 검토 담당자의 참여 가능 여부, 시험 범위를 합의하기 전까지 6주 일정은 잠정안입니다. CRM 교체는 포함하지 않습니다.
이어서 제안한 업무가 수행되었음을 무엇으로 보여 줄지 정합니다. 합의한 절차 설명, 변경 내용의 기록, 시험에서 확보한 관찰 결과, 그리고 결론 내릴 수 없었던 부분이 이에 해당합니다. 견적 처리 시간을 몇 퍼센트 줄이겠다는 보장과는 다릅니다. 시험을 제대로 수행했더라도 변경안을 확대해서는 안 된다는 결과가 나올 수 있습니다.
승인 뒤에 다른 국가, 새 시스템 연동, 추가 성과를 이 메모에 조용히 넣지 마세요. 견적을 수정하기 전에 새 요청이 필요한 자료와 업무를 어떻게 바꾸는지 보여 줍니다. 마찬가지로 회의에서 아무도 반대하지 않았다는 이유로, 답을 얻지 못한 선행 조건에 고객이 동의했다고 간주하지 않습니다.
회의 답변을 실제 업무 범위로 옮기기
고객이 한 팀의 시범 운영을 선택했지만 개별 견적 기록은 제공할 수 없다고 답했다고 가정해 보세요. 그 답은 작업 내용을 바꿉니다. 업무를 관찰하는 시간을 마련하거나 다른 출발점이 필요할 수 있습니다. 일정표 아래에 묻어둘 사소한 조건이 아닙니다. 범위가 이미 승인되었다면 약속을 조용히 바꾸지 말고, 새 요구사항을 프로젝트 변경 요청으로 제시해 승인된 계획과 비교하세요.
회의 후에는 선택한 경로를 수정하고, 아직 부족한 자료와 이를 해결할 담당자를 기록합니다. 그다음 합의 내용을 산출물, 책임 분담, 견적으로 구체화하세요. 유용한 컨설팅 발표 자료는 이런 선택을 드러냅니다. 불완전한 요청서를 완성된 계획처럼 보이게 만드는 자료가 아닙니다. 합의한 시범 운영안을 설명할 때는 문제·해결책·근거로 구성하는 발표 방식으로 예시가 보여 주는 것과 시험에서 확인해야 할 것을 구분할 수 있습니다.
