First, it's important to distinguish: this is about choosing a channel, not about technical superiority.
Both approaches share a common underlying process: "understanding the user, gathering information, and executing actions." The difference lies in the entry point. Voice-based customer service exists on the phone: it offers immediate, hands-free interaction, is friendly to older and mobile users, but every second spent on the call incurs a cost, and mistakes require restarting. Text-based chatbots exist on websites and LINE: they allow for detailed responses, the ability to include links and images, and conversations are automatically recorded, but they cannot reach customers who only prefer to call. Therefore, the first and most important question is always: "Where are your customers currently accessing you from?"
What are the key differences in the cost structures?
The cost structure of text-based chatbots is relatively straightforward: a one-time setup cost plus API usage fees. Voice-based customer service adds three additional layers: a telecommunications layer (monthly fees and call minutes), a voice recognition and synthesis layer (billing based on audio usage), and a concurrency layer (the number of simultaneous calls determining network and computing resources). This is why our text-based chatbot MVP has a publicly advertised price (TWD 30,000), while voice-based projects insist on assessing the environment first before providing a quote. You rarely see companies offering prices without understanding the specific needs of PBX systems, concurrency requirements, and recording demands.
Different failure modes require different safety net designs.
The primary risks associated with text-based robots are related to understanding: misinterpreting intent, model hallucinations, and answering incorrectly – these can be mitigated through the quality of the knowledge base, limitations on responses, and the use of human-in-the-loop mechanisms. In addition to these, voice-based customer service introduces further risks: misidentification, background noise, accents, and call interruptions. Therefore, voice-based processes must include features such as confirmation of key information, escalation to a human agent when confidence is low, and the ability to save the state of the conversation after a disconnection. When evaluating vendors, directly ask "What happens when the system mishears?" and pay close attention to their responses, as vague or idealistic answers are often misleading.
How to choose: Starting with customer behavior, not with technology
The approach is practical: review your current customer service records. If a large portion of your interactions are via phone and your customer base prefers verbal communication (e.g., local services, elderly customers), prioritize voice-based solutions; if your interactions primarily occur through LINE and website forms, and your customers prefer text-based responses (e.g., e-commerce, appointment services), prioritize text-based solutions. Start with the channel that handles the largest volume of interactions, validate the process, and then expand to the other channel. When budget is limited, a text-based chatbot is a more accessible starting point, as it eliminates the complexity of voice and telecommunication channels.
Using both: Share the backend, while the interface serves as the entry point.
A mature architecture treats voice and text as two entry points within a single system: a shared knowledge base (with maintenance) and a shared backend for actions (processing orders, creating work orders, and transferring tasks through a single API). Voice communication should be concise and conversational, while text can include links. The GoGoCha case study, which we have publicly shared, exemplifies this approach: three entry points – phone, website, and LINE – receive the same backend for order processing. The order of implementation is flexible; the key is to design the backend with multiple channels in mind from the outset, to avoid having to redo it later.
