주로 몇 가지 측면에 반영됩니다.

1. 소프트웨어 제품 또는 프로젝트는 다른 제품과 달리 영업 사원이 프로젝트에 대해 어느 정도 이해 (예: 사용자의 업무 및 소프트웨어 기능) 해야 사용자와 더 잘 소통하고 신뢰를 쌓을 수 있다.

2. 일반 소프트웨어 프로젝트 주기가 길고, 환금 관련 요소가 비교적 복잡하므로, 회사의 소프트웨어 특성과 결합하여 진지하게 고려해야 한다.

관리규정제도를 제정하는 목적은 소프트웨어를 잘 팔고, 사용자의 인정을 받고, 회사가 장기적으로 발전할 수 있도록 하기 위함이다. 소프트웨어 회사들은 단기적인 이익을 추구하는 것을 가장 두려워하며, 너는 정책을 세울 때 몇 가지 전략을 충분히 고려할 수 있다.

1, 판매 평가에 중점을 둡니다.

2. 지불의 품질은 개발 구현 팀의 업무 품질과 효율성과 함께 고려해야 하며 판매 결과를 결정해야 합니다. 이 문장 의 뜻 은 공사 대금 문제 는 집행 팀 이 초래한 것 이 있을 수 있으며, 판매 에 대해 반드시 어느 정도 설이 있을 것 이다. 이것은 판매가 더 많은 일을 하도록 장려할 수 있다.

3. 영업 사원에게 소프트웨어에 해당하는 업무 지식과 소프트웨어 기능을 숙지하도록 독려하여 판매가 함부로 말하지 않도록 합니다.

규칙과 제도를 수립하는 전제는 명확한 판매 목표를 세우는 것이며, 판매 목표는 회사의 발전 계획과 밀접한 관련이 있다.

판매 목표를 설정할 때 각 개인과 영업 부서에 대해 명확한 판매 목표를 설정하거나 각 개인에 대해 여러 등급 목표를 설정할 수 있습니다. 달성 가능한 지표는 "점프" 하면 된다. 판매 실적은 커미션과 임금과 연계되어야 하며 즉각적인 보수가 있어야 한다. 목표를 달성하지 못하면 임금을 낮춰야지, 손이 약해서는 안 된다.

이것을 생각하면 아직도 막막하다.

너는 너의 회사의 규모, 환경, 특색 등을 소개하는 것이 좋겠다. 질문을 할 때는 상세히 해야 대답하는 사람이 더 표적이 될 수 있다. 감사합니다

3, 프로젝트 구현

예를 들면