Customer Service System Architecture

The problem: when service quality depends too heavily on individual experience

The team analyzed and designed the architecture for a Customer Service management system in the passenger transport industry, inspired by the operating model of Phương Trang bus lines. Passenger transport businesses typically handle a high volume of customer requests — complaints, support, ticket information changes, and other issues that arise during service use. Without a centralized management system and a unified handling process, service quality ends up depending heavily on each employee’s individual experience, leading to inconsistent information and poor control.

The project aimed to standardize the process for receiving and handling customer requests, clearly define the system boundary, model the data flow, and design the overall architecture before any software implementation. Beyond traditional customer service functions, the team also proposed building a Knowledge Base to store and share internal knowledge, helping standardize how tickets are handled and improving service quality.

Role: business analysis and system architecture design

Within a 5-person team, led the work related to business analysis and system architecture design:

• Designed the organizational structure diagram
• Built the overall business process
• Designed the process for building and maintaining the Knowledge Base
• Designed the Data Flow Diagrams (Context, Level 0, Level 1, and further detail levels within the assigned scope)
• Designed the system’s overall architecture using a layered model
• Edited and finalized the report documentation, designed the presentation slides
• Helped review the BPMN processes to ensure consistency between the system architecture and the analysis documents

The process: viewing the system through an architectural lens, not just a functional one

The workflow followed these steps:

1. Analyze the problem and define the system scope
2. Build the organizational structure
3. Design the overall business process
4. Analyze the Knowledge Base management process
5. Build the Data Flow Diagram from the Context Diagram down to Level 2
6. Design the overall architecture using a layered model
7. Define the system components and the responsibilities of each layer
8. Finalize the documentation and present the solution

The most time-consuming part was designing the Knowledge Base process — it required multiple rounds of research and revision to build an appropriate workflow, especially the content approval mechanism before publication, to ensure the accuracy and consistency of the knowledge used across the entire customer service system.

Results

• Completed the architecture model for the Customer Service system
• Standardized the process for receiving tickets, handling them, and managing internal knowledge
• Designed the system using a three-tier architecture: Presentation Layer, Business Layer, and Data Layer
• Built a complete set of DFDs describing data flow from a high-level overview down to fine-grained detail
• Proposed a Knowledge Base process with mechanisms for collecting, drafting, approving, publishing, and maintaining knowledge to ensure data accuracy and consistency

What I’m proudest of

This course changed how software gets built, conceptually. Previously, the instinct was to start writing code first, but after this project, it became clear that a good system needs to start with business analysis, defining the system boundary, modeling the data flow, and designing a clear architecture. The part invested in the most was the Knowledge Base process — it took multiple rounds of research and revision to land on an appropriate workflow.

The biggest takeaway

The project taught how to view a system through an architectural lens rather than just focusing on functionality, and how to define the system boundary and the responsibility of each component. It clarified the difference between Process, Data Flow, Data Store, and External Entity in a DFD, how to decompose a DFD from the Context Diagram down to detailed levels, and the role of Layered Architecture in separating the interface, business logic, and data. More importantly, it clarified that a Knowledge Base isn’t just a collection of FAQs — it’s a knowledge management system with a process for collecting, reviewing, publishing, and maintaining content, designed to help staff handle real situations consistently.

Limitations

The project stayed at the analysis and architecture design stage and wasn’t actually implemented. The processes were built based on business research and simulation rather than verified in a real operating environment. Performance, scalability, and other non-functional requirements weren’t evaluated at the implementation level.

If I did it again

• Add Microservices and Event-Driven Architecture for comparison against the traditional layered model
• Design additional non-functional requirements such as scalability, availability, and security
• Model additional Sequence Diagrams and API contracts between components
• Design a more detailed authorization and Knowledge Base management mechanism
• Build a prototype or Proof of Concept to validate the designed architecture before actual implementation