Design and Architecture of a High‑Performance Customer Service System for Good Installment Business

Architecture Design Principles

Customer service is a fallback solution to improve user experience when the primary service is imperfect; with rapid growth of the Good Installment business, a robust customer service layer becomes essential. Two core design principles are highlighted: ensuring system stability under traffic peaks and improving first‑call resolution and user satisfaction.

Business Architecture

The call flow is divided into three layers: the line layer (concurrent phone lines), the communication component layer (call parsing and distribution), and the application layer (customer service system, post‑loan system, tele‑sales system, etc.).

Line: supports concurrent phone lines.

Communication Component: parses and distributes calls.

Application Layer: general business systems such as the customer service system.

Technical Architecture

During rapid business growth, the customer service system faced issues such as slow internal data flow after call connection, unresponsive CTI operations, and inaccurate monitoring data. The solution separates the system into two layers: the application layer (customer service system) and the middle layer (communication components).

Application Layer Design

Provide a unified call data API for business systems.

Offer a visual workflow engine or API integration.

The goal is a unified management platform with a visual entry point, featuring two core designs: a high‑efficiency communication component for external call intake and a fast internal flow that drives a workflow engine.

Workflow Engine Creation

When a user calls, the system records the request as one or more tickets. If the frontline agent cannot resolve the issue, a ticket is created and routed to the responsible department, with every step and result logged for traceability. The engine supports visual configuration, automatic ticket creation, SLA timing, and multi‑level alerts (message, SMS, phone).

Example flow for a discount request:

User intent is recognized by a voice bot and matched to a discount rule template.

Process: Start → Main Approval → Manager Approval → Department Head Approval → End.

Routing rules set thresholds (e.g., amount < X: single‑level approval; ≤ Y: manager approval; > Z: department head).

Alerts are configured per node (e.g., 1‑hour warning at supervisor node with escalating reminders).

Timing stops at the end node.

Core Components

Flow: defines process ID, permissions, and basic info.

Todo: smallest executable branch assigned to a person.

Node: stage nodes (create ticket, approval, processing, reminder, close, etc.) with extensibility.

People: built‑in handlers (specific users, groups, organizations) with assignment strategies.

Control: routing conditions between nodes.

SLA: time limits per node with automatic countdown.

Warning: multi‑level alerts (WeChat, SMS, email, phone) when SLA is breached.

Engine Benefits

Seamless IVR‑to‑engine integration.

Visual, extensible UI reduces code maintenance.

Customizable processes, rules, and thresholds.

Multi‑tenant, data isolation, hot deployment.

Standardized API.

Communication Component Design

The previous monolithic communication service handled call parsing, data collection, CTI processing, and real‑time push, leading to delays and unresponsive CTI under high load. The new design follows these principles:

Decompose the service into independent, backup‑ready components.

Add a pluggable Callcenter routing component for dynamic resource allocation.

Enable active‑standby routing to share load during traffic spikes.

Implement traffic control thresholds to divert calls to appropriate channels (smart IVR, online chat, keypad IVR).

Introduce automated three‑level degradation with auto‑recovery.

Component breakdown:

Data Collection: one component per data source, unified push interface.

CTI Component: soft‑phone service for call handling.

Data Reception: aggregates data from collectors and CTI.

Data Aggregation: computes, stores, and forwards standardized call metrics.

Data Push Service: external APIs for downstream consumption.

Control Console: calculates resource usage, decides routing, and triggers traffic shaping.

External interfaces include REST APIs and WebSocket streams for front‑end consumption and real‑time monitoring.

Project Outcomes

The implementation progressed through three stages:

Stage 1 – Monolithic architecture: low first‑call resolution, SLA, and satisfaction.

Stage 2 – Multi‑active architecture: integrated financial services, moderate metrics.

Stage 3 – High‑availability architecture: screen‑pop assistance, dynamic pressure sensing, rapid scaling, circuit‑breaker, achieving metrics above industry average.

Future Plans

The current call‑center architecture is mature but tightly coupled with the customer service system. The next phase will encapsulate the high‑availability stack into a telephony middle‑platform, providing a unified SDK for all inbound/outbound scenarios across the financial ecosystem.

Core design principles for the middle‑platform:

Aggregate all channels under a single entry point and expose a unified SDK.

Enhance extensibility with a centralized control center.

Strengthen core value and adaptability to downstream business systems.