AI 음성 고객 서비스 비용은 일반적으로 초기 설계 및 통합 비용과 지속적으로 발생하는 전화, 음성 인식, 음성 합성, 모델, 장비 및 유지 보수 비용으로 나뉩니다. 만약 공급업체가 먼저 구축 방식(직접 연결 또는 외주), 급증 상황, 기존 PBX, 기업 API, 녹음 정책 및 인력 배치 등에 대해 질문하지 않고, 마치 정확한 가격을 제시하는 것처럼, 그 가격은 실제로 서비스를 이용할 수 있는 범위를 제대로 반영하지 못하는 경우가 많습니다.
맞춤형 프로젝트 구축 비용은 일반적으로 모델 라이선스 구매 비용이 아니라, 기업 프로세스를 테스트하고 복원할 수 있는 시스템으로 만드는 데 드는 비용입니다.
지속적인 비용에는 전화 번호 및 통화 분, 음성 인식, 음성 합성, 언어 모델, 서버, 모니터링, 음성 녹음 저장 및 공급업체의 유지 보수가 포함될 수 있습니다. 각 공급업체의 요금 단위가 다르므로, 단일 모델의 분당 가격만 비교하는 것은 적절하지 않습니다. 한 통화는 통신, 음성 및 모델 서비스를 동시에 사용할 수 있습니다. 견적에는 제3자의 실제 사용량과 개발사의 유지 보수 비용을 명확하게 구분해야 합니다.
| 비용 유형 | 일반적인 요금 방식 | 평가 전에 필요한 정보 |
|---|---|---|
| 전화 및 통신 회선 | 월별 요금, 분 단위 또는 동시 통화 요금 | 입선/출발, 국내/해외, 동시 |
| 음성 및 모델 | 오디오 분, 문자, 토큰 또는 요청 수 | 언어, 평균 통화 시간, 작업 복잡도 |
| 기업 통합 | 일회성 개발 및 테스트 | PBX, API, 권한, 테스트 환경 및 데이터 계약 |
| 운영 및 유지 관리 | 월 구독료, 근무 시간 또는 SLA 수준 | 감시, 녹음 보관, 좌석, 근무 및 변경 빈도 |
평균적으로 하루에 100통 정도의 통화가 발생하며, 이는 분산된 형태일 수도 있고, 특정 시간대에 집중될 수도 있습니다. 후자의 경우, 더 많은 동시 통화 처리 능력, 음성 처리 용량, 기업 API 처리 용량, 그리고 인력 지원이 필요합니다. 월별 총 분량을 기준으로만 계산하면, 특정 시간대에 통화량이 급증할 경우 연결이 지연되거나 실패할 수 있습니다. 따라서 월별 통화 횟수 외에도, 특정 시간대의 통화량, 동시 통화 가능 여부, 그리고 허용 가능한 대기 시간을 제공하는 것이 좋습니다.
다음 항목들은 일반적으로 데모 버전 이후에 등장하지만, 실제 운영 여부에 직접적인 영향을 미칩니다.
모든 공급업체는 다음 항목에 대해 동일한 형식으로 답변해야 합니다: 통화 방향, 번호, PBX, 동시 통화, 언어, 작업, 필수 필드, 기업 API, 인적 지원, 녹음 정책, 배포 방식, 예상 사용량, 유지보수 책임 및 검수 기준. 만약 한쪽만 음성 모델에 대한 정보를 제공하고 다른 쪽은 전화 및 시스템 통합에 대한 정보를 제공한다면, 두 항목의 총 비용을 직접 비교할 수 없습니다.
먼저 검증 가능한 시나리오를 예시로 들어 요구사항을 설명합니다. 예를 들어 "업무 시간 동안 통화 연결, 출근 시간 동시 3통화, 5가지 필수 정보 수집, 작업 주문 생성, 낮은 신뢰도 및 고객 불만 처리 2개의 인력 배치"와 같이 구체적으로 명시합니다. 그런 다음, 공급업체에게 POC(Proof of Concept), 실제 구축, 월 고정 비용, 예상 사용량 및 초과 사용량 단가 등을 각각 제시하도록 요청합니다. 이는 공개적인 견적 약속이 아니라, 예상치 못한 조건들을 명확히 밝혀, 서비스 제공 후 갑자기 전화, 녹음, 또는 인력 배치 등이 포함되지 않아 발생하는 문제를 예방하는 것입니다.
일반적인 챗봇의 초기 비용은 전화 시스템의 가격을 나타내는 지표가 될 수 없습니다. 전화 시스템에는 통신, 실시간 연결, 부가 기능, 음성 녹음, 인력 배치 및 오류 발생 책임 등이 포함됩니다. 따라서, 환경을 파악하기 전에 낮은 초기 비용을 제시하면 기업이 전체적인 기능이 포함된 것으로 오해할 수 있습니다. Falcon은 먼저 고객의 요구 사항과 환경을 파악한 후, 구축, 제3자 사용량, 유지 보수 비용 등을 분리하여 제시합니다.
검증 가능한 공개 사례 및 증거
GoGoCha AI 전화 및 즉시 배달 기술 사례현재 전화 방식, 통화 후 시스템 동작 및 예외 처리 방식을 논의합니다. 요구 사항을 제시한 후, 데모 시간, 시연 범위, POC(Proof of Concept) 필요 여부를 확인합니다.
