Customer Support 360
A customer asks about an order, but the information is split across several systems
A support agent needs the latest customer details, order status, and open-ticket context before responding. Looking in several systems can slow down the conversation and leave the agent working from an outdated view.
What you will build
This tutorial creates a small Customer Support 360 view. It synchronizes customers, orders, and support tickets from MySQL into VeloDB, then uses one SQL query to show the information related to a customer who has an open, high-priority ticket about an unshipped order.
When the source order ships and the support ticket is resolved, the same VeloDB query no longer returns that case as needing attention.
How the example works
Customer, order, and ticket changes in MySQL
↓
Initial and incremental synchronization into VeloDB
↓
Join the three current-state tables
↓
Find customer cases that need follow-up
The scenario uses four parts of an operational analytics pattern:
- Bring related operational tables together. The tutorial copies the selected customer, order, and ticket tables into a VeloDB warehouse.
- Keep the view current. Incremental synchronization captures later source updates after the initial copy.
- Add context with SQL. A join connects the customer, their order, and their support ticket in one result.
- Focus on the cases that need attention. The query filters for an open, high-priority ticket and a paid order that has not shipped.
The sample does not measure throughput or compare database performance. Its purpose is to make the data path and the operational query easy to reproduce.
Why VeloDB fits this workload
| Requirement | VeloDB capability used in this scenario |
|---|---|
| Avoid reporting queries against the transactional application database | The selected MySQL tables are synchronized into a VeloDB warehouse for analysis. |
| See the latest customer context without repeating a manual export | Initial load and incremental synchronization copy existing data, then capture later changes. |
| Bring a customer, their order, and their ticket into one answer | SQL joins combine the related operational records. |
| Find the cases that need action first | SQL filters narrow the result to open, high-priority tickets linked to unshipped orders. |
For larger datasets, a selective search pattern can also use an inverted index to reduce unnecessary scanning. That optimization is not required for this small tutorial.
Learn more about the underlying capabilities
- Native CDC for MySQL and PostgreSQL explains the initial-load and continuous-sync pattern used here.
- Real-time update deep dive explains the engine concepts behind update-heavy analytical workloads.
- How inverted indexes work explains the optional index pattern for selective queries.
- The ZTO Express story is a separate production example of real-time analysis with inverted indexes.
These linked articles describe their own workloads and evidence. This tutorial uses synthetic data and is not a performance benchmark.
Choose your source database
This scenario currently provides a MySQL walkthrough. It uses only synthetic data and can be adapted to another supported source database when that version is needed.
| Source database | Tutorial |
|---|---|
| MySQL | Build a Customer Support 360 View from MySQL with VeloDB |
The MySQL tutorial includes the source schema, data-import settings, SQL query, source update, and verification steps.
Return to the Real-Time Operational Analytics overview to see how this scenario maps to the broader product capabilities.