How to integrate AI voice customer service with real-time dispatch | GoGoCha technical case study

Integrate the brand website, AI call center, instant dispatch, LINE Bot, and driver/passenger app into a single backend system.

The brand website features a shared dispatch process using phone, website, and LINE entry.

GoGoCha driver and passenger app screenshots — The app displays driver and passenger interfaces for accepting and receiving immediate tasks and notifications.

Background of the Problem

Users include elderly individuals, travelers, and corporate clients. Entry points may include phone, website, or LINE. The system must allow information to flow into a single dispatch process while maintaining the ability for human intervention.

Implementation Methods

—Send information obtained from the AI call center to a shared backend, preventing the phone entry from becoming an isolated data silo.
—Build the instant dispatch backend using Express, PostgreSQL, Redis, BullMQ, and Socket.IO.
—The website fare calculation should first call a real-time fare API. If the API fails, provide a clear alternative result based on local rules.
—Design the interface for elderly users with large fonts, voice priority, and high contrast.

Falcon's Actual Scope of Responsibility

Brand website and fare calculation interface
AI call center entry and task data structure
SmartDispatcherV2 – instant dispatch backend
Integration of LINE Bot, driver/passenger app, and operational backend

The data flow from the AI call center to dispatch.

01Users can submit ride requests via phone, website, or LINE.
02The system collects location, contact, and task information and sends it to the shared dispatch process.
03The backend uses PostgreSQL to store status, BullMQ to handle queues, and Redis/Socket.IO for real-time synchronization.
04Drivers, passengers, and the operational interface all have access to the same task status.

Limitations, Failures, and Alternatives

—Maintain human intervention when information is insufficient or the AI cannot reliably confirm, and do not treat guesses as dispatch data.
—When the website fare API fails, display local rules and limitations, and do not pretend that a formal quote has been successful.
—Use queues and real-time communication to handle connections in layers, preventing a single connection failure from resulting in the task being lost.

How to Verify Evidence

✓Users can verify phone, website, LINE, and fare calculation entry points through the public brand website.
✓Use the public app screen and website screen to demonstrate the range of products accessible through different entry points. This does not include private passenger or driver data.
✓The technical architecture is based on the actual scope of responsibility for Falcon; it does not disclose operational volume, connection rates, time savings, or formal SLAs.

Publicly Available Measurements and Capabilities

Dispatch product goals

3 seconds

The product functionality goals do not mean that all real ride requests can be accepted by drivers within three seconds.

Verify Public Sources

Primary entry points

Phone/Website/LINE

The three entry points share a common backend process, covering the system's scope.

Accessibility design

Large font size and high contrast

Based on the publicly available interface functionality, this does not equate to a third-party accessibility certification.

Disclosure and Limitations

This page describes the publicly available product capabilities and the Falcon technical scope; it does not disclose fleet revenue, order volume, time savings, connection rates, or call recordings or call SLAs. "3 seconds" is a product design goal, not a guarantee that every ride request can be accepted by a driver within three seconds.