The Problem: First-Response Time and Cost Per Ticket
A 501-2000 employee fintech company in the USA handles 12,000 support tickets per month. The average first-response time is 4.2 hours, and the cost per ticket is $18. The company’s support team is stretched thin, and the first-response time is a key driver of customer churn. The company has tried to cut costs by hiring more support agents, but the cost per ticket has not decreased. The company has also tried to use a commercial AI assistant, but the assistant is not PCI DSS compliant and cannot handle card numbers. The company needs a solution that is PCI DSS compliant, can handle card numbers, and can cut the first-response time and the cost per ticket. The solution is a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The voice agent is built by Forfis, a product studio with eight years of delivery experience. The voice agent is built in 4 weeks, and the cost per ticket is cut by 40%.
The Mechanism: On-Premise Models and Voice Agent Architecture
The voice agent is built on an on-premise model, which is a Llama 3 70B model. The model is fine-tuned on the company’s ticket data, which includes the ticket category, the ticket priority, and the ticket resolution. The model is stored on the company’s hardware, and the model is updated quarterly. The voice agent uses a speech-to-text model to transcribe the call, a language model to classify the ticket, and a text-to-speech model to generate the response. The speech-to-text model is open-weight and runs on the company’s hardware. The language model is also open-weight and runs on the company’s hardware. The text-to-speech model is a commercial API, because the quality of the voice is important for customer-facing interactions. The integration with the CRM and helpdesk is via their APIs, which are well-documented and stable. The integration with Notion/Confluence is a read-only integration that pulls the company’s documentation into the agent’s context.
The Trade-Offs: On-Premise vs. Commercial APIs
The trade-off between on-premise models and commercial APIs is a key decision in the architecture. On-premise models are more expensive to build and maintain, but they are more secure and more compliant. Commercial APIs are cheaper to build and maintain, but they are less secure and less compliant. For a fintech company that is PCI DSS compliant, the on-premise model is the right choice. The on-premise model ensures that the raw audio and transcript never leave the company’s network, satisfying PCI DSS Requirement 9.4.1 for physical and logical access controls. The on-premise model also ensures that the model is not trained on the company’s data, which is a key requirement for PCI DSS compliance. The trade-off is that the on-premise model is more expensive to build and maintain, but the cost is offset by the reduction in the cost per ticket.
The Recommendation: A 4-Week Audit and Pilot
The recommendation is to start with a 4-week audit and pilot. The audit takes 5 business days, and the pilot takes 3 weeks. The audit includes a process mapping, a data collection, and a cost model. The pilot includes a voice agent that is built on an on-premise model and integrated with the company’s CRM, helpdesk, and Notion/Confluence. The pilot is measured against the baseline, which is the current first-response time and the current cost per ticket. The pilot is tuned based on the measurement, and the rollout is planned based on the pilot’s results. The rollout is a phased rollout, which starts with a small group of tickets and expands to the full ticket volume. The rollout is measured against the baseline, and the cost per ticket is cut by 40%.
Leave a Reply