RFP를 만드는 사람과 RFP에 대응하는 사람
최근 이런 메시지를 담은 광고를 본 적이 있습니다. 광고의 결론은 분명했습니다. RFP에 대응하는 기업이 아니라, RFP를 함께 만드는 기업이 되어야 한다는 것이죠.
왜냐하면 RFP를 만드는 과정에 참여한 기업은 더 이른 시점에 고객과 대화했고, 고객의 문제뿐 아니라 구매 판단 기준 자체를 함께 고민했기 때문입니다.
실무에서 보면 많은 고객이 자신의 문제는 비교적 잘 설명합니다. 하지만 그 문제를 해결하기 위해 무엇을 기준으로 솔루션을 선택해야 하는지는 쉽게 정리하지 못합니다.
그래서 여러 벤더와 미팅을 하고, RFI를 요청해 최대한 많은 정보를 모으려 합니다. 프리세일즈 입장에서 RFI는 종종 이렇게 받아들여집니다. '요구사항에 Yes/No로 성실히 답하면 되는 단계.'
현실적으로 틀린 말은 아닙니다. RFI에 정확하고 빠르게 답하는 것 자체는 고객에게 분명 도움이 됩니다. 다만 이 단계에서 고객이 정말로 필요로 하는 것은 단순한 기능 지원 여부가 아닙니다.
고객은 RFI를 통해 구매 기준을 만들기 위한 단서를 찾고 있습니다. 그래서 이 단계는 단순한 정보 전달이 아니라, 구매 판단이 형성되는 중요한 시점이 됩니다.
개인적으로 저는 RFI 대응 단계가 프리세일즈에게 매우 중요하다고 생각합니다. 고객은 RFP 단계에서는 벤더들이 각자에게 유리한 요구사항을 넣으려 한다는 점을 어느 정도 인식하고 경계합니다.
반면 RFI 단계에서는 상대적으로 중립적인 정보 제공으로 받아들이는 경우가 많습니다. 구매 기준이 어느 정도 정리된 이후에는 공정성 이슈 때문에 벤더와의 추가 논의를 오히려 줄이기도 합니다.
그래서 RFI는 공식적이고 합법적으로 구매 기준에 영향을 줄 수 있는 거의 유일한 기회가 되기도 합니다. 제 프리세일즈 경력 중에도 이런 기회는 많이 있었습니다. 돌이켜보면, 그때 도움이 되었던 접근 방식에는 공통점이 있었습니다.
판단 기준을 묶거나 나누자
(예) RBAC는 단독 비교 항목이 아니라 운영 승인 여부를 가르는 요건입니다. 권한 모델, 감사 로그, 비상 권한 운영과 함께 평가하는 것이 합리적입니다. -> 경쟁 열위 방어만이 아닌, 고객 보안팀이 판단 기준 결정에 참여할 수 있도록 함
수치를 비교하지 말고 시나리오로 판단하자
(예) TPS 수치는 측정 조건에 따라 달라집니다. 벤치마크 수치 비교보다는 실제 트래픽 시나리오와 성능 저하 시 운영 대응을 함께 검증하는 것이 적절합니다. -> 경쟁사 제품이 성능이 더 좋을 수 있지만, 적어도 고객 운영팀의 의견을 구하도록 함
고객의 평가 기준을 단순화시키자
(예) 암호화는 대부분 ‘지원’으로 답변됩니다. 키 관리 및 감사 대응이 불가능한 경우 탈락 기준으로 정의하는 것이 평가가 단순해 집니다. -> 경쟁사 제품을 탈락시키려는 의도보다 고객의 평가 기준 단순화를 강조
가중치를 알려주자
(예) 모든 항목을 동일 비중으로 평가하면 실제 리스크가 반영되지 않습니다. 도입 시 제약과 운영 리스크를 분리해 가산점을 주는 것이 효과적입니다. -> 근거없는 주장이 아닌 핵심 기능에 대한 우선 순위 정리를 권장
이 예시들은 공통점이 있습니다. 목적이 ‘우리 제품 홍보’ 보다는 ‘평가의 정확성’에 있다는 점입니다. 오해를 줄이고, 운영 리스크를 낮추며, 의사결정을 단순화하는 것이 목적입니다.
그래서 표현 방식도 대체로 비슷합니다. '~로 정의하는 편이 평가에 도움이 됩니다.' '이 방식이 의사결정에 도움이 됩니다.' '~팀의 참여가 정확한 구매 기준 결정에 도움이 됩니다.'
RFI에 Yes/No로만 답하면 사실 고객도 답답해합니다. 이 단계에서 어떤 관점을 제시하느냐에 따라, 구매 기준이 정리되고 이후 평가의 흐름도 달라집니다.
