제안서 잘 쓰려면 이것만은 지키자!
처음 제안서를 쓰게 되었을 때 어려움을 접하게 되는 점이 많은 것 같다.
많은 제안 작업 중에서 처음 제안서 쓰게 되었을 때가 가장 기억에 남는데 그때 썼던 제안서를 아직도 보곤 한다. 잊지 않기 위해서인지 아니면 소중한 기억 때문인 건지...
이거랑 똑같이 쓰면 되니까 걱정 말라던 선임의 말을 믿고 출발했던 제안 작업이 수포로 돌아갈 때 그렇게 아무렇지 않게 얘기했던 선임의 호통이 떠오른다.
뭘 잘못 한건 지도 모르고 그걸 가르쳐주는 사람도 없었으니까.. 나 혼자 해결해야만 했었다.
절치부심하고 두 번째 제안 땐 정말 죽을힘을 다했던 거 같다. 시간도 촉박했고 양도 많았다.
이런저런 콘셉트 잡는 데만도 하루가 지나갔고 목적 있는 제안을 위해서 여러 가지 방법의 서브 제안들을 만들어갔다.
그리고 하나로 합치고 다시 읽어 보고 다시 수정하고 제안 결과는 수주였으나 기술평가(제안서의 평가)에서 조금 못 미치는 근소한 점수 차이였다.
무엇인가 다른 방법을 써야 하는데.. 항상 이런 생각들이 있었던 것 같다.
세 번째부터 제안서 작성은 그렇게 신경 쓰지 않았다.
장표 한 장에 신경 쓰는 것보다 큰 틀을 우선 보았다. 제안요청서에 적혀 있는 담당자에게 연락해서 제안을 하게 된 배경을 상세하게 물어보고 또 담당자로써의 고충들을 물어보았다. 그땐 그걸 제안요청서에서 못 찾았기 때문에 물어본 것이었는데 담당자는 좋은 인상을 받았던 거 같다.
그리고 제안서를 쓰게 되니 무엇을 찾아서 무엇을 넣어야 하는지 확실하게 알 것 같았다.
모르면 물어보면 되는데.. 그 담당자 얘기론 이렇게 물어보는 업체가 한 번도 없었다고 한다. 그래서 더 답답했다고 했었다.
내가 원하는 것은 이것인데 하나의 문서로(제안요청서) 전달되지 않는다는 것이다.
그도 그럴 것이 그 많은 제안 요건을 몇십 장의 제안요청서로 어떻게 나열하겠는가?
솔직하게 추가했으면 하는 제안들도 많이 얘기해주더라..
담당자와의 연락을 영업팀에 맡겨 제안서의 문서 작성만 하는 것이 가장 잘못된 제안 작업인 듯 싶다.
오래되지 않았지만 제안서 작업 시 그래도 이 정도면 된다 싶은 몇 가지의 사항을 정리해보았다.
담당자의 인식에 제안업체를 각인시켜야 한다. (이만한 영업이 있을까 싶다.)
제안의 배경과 제안의 목적을 물어봐라.
제안 내용 중 중요도를 체크해라 (요소별 (기획/디자인/개발...)로 중요도를 물어보면 답은 나온다.)
담당자로써의 고충을 본인이 생각해봐라
담당자는 어떤 업체가 들어오는지 중요하지 않다. 어떤 사람이 들어오는지가 중요하다. 자신의 생각을 읽는 개발자가 들어온다면 그것이 가장 중요한 제안의 내용이 될 것이다. (간혹 정해놓은 업체가 있기도 하다 그것은 그 업체의 개발자들을 알기 때문이다.)
제안 작업 시 가장 중요한 것은 제안의 목적이다.
제안의 목적을 다방면으로 리스트업 해라
중요도에 따른 분류로 최종 목적을 잡아라.
제안요청서의 내용만으로 제안서를 작성한다면 그것은 제안이 아니다. (기본만 하겠다는 업체에게 손을 들어줄 평가위원은 없다.)
추가 제안의 비용 산정을 한 후 최종 목록을 뽑아라.
추가 제안에 대한 표시를 해라 (장표에 유치하지만 별표를 한다던지 그냥 넘기지 못하도록 꼭 읽을 수 있도록 표시해야 한다, 제안서를 평가하는데 제안서의 디자인을 높이 보는 데는 없다. 물론 눈에는 좋겠지만...)
제안서의 모든 장표를 작성한 후 중요도를 체크하라.
중요도에 따른 표시를 눈에 띄도록 해라
기본적으로 제안서의 작업보다 제안서 작업 이전의 행동들이 제안을 수주하느냐 못하느냐를 결정하는 것 같다.