Business Systems Architecture — Claims & Complaints Processing

Note
This case study is a 1:1 English translation of a live design response originally written in Polish.The solution was produced live, within a limited time window, based on partial business context and without research.The wording reflects the original reasoning style and structure.

1. Live Design Question
You are a business systems architect working for a retail electronics company operating:
• 50 physical stores,
• an online sales channel,
• approximately 500,000 transactions per month.

The company faces critical problems in its claims and complaints process:
• average handling time: 18 days (target: 7 days),
• 35% of claims require repeated customer contact,
• no transparent status visibility for customers,
• different processes for online and physical stores,
• siloed departments (customer service, warehouse, accounting, service),
• conflicts of responsibility between store managers and the claims department.
• Most office workers are aged 50+.

Task (15 minutes):
Design a target business system architecture, including:
• process model,
• organisational model,
• key success metrics,
• high-level transformation plan,
• main risks.
Think as a business systems architect, not as an IT specialist.

2. My Live Answer (verbatim, translated 1:1)

First, we need to identify where the problem is — which is the lack of unified communication.
Since most office employees are 50+ years old, we will not introduce changes to the existing systems.
Instead, we will create a solution that connects all systems into one place.
⸻
Let us establish a decision hierarchy.
A claim first goes to the service department, which determines its status within 72 hours.
Then it goes to the head of the claims department.
This will be a new department consisting of: • five people handling customer contact regarding claims, • two people analysing claims, • and one department manager.
This department has 24 hours to make a decision regarding the claim.
The final step is accounting, which has 72 hours to execute a refund.
⸻
If the service department decides to repair the product instead of issuing a refund, they have 120 hours to complete the repair or to provide information to the claims department about the expected repair time.
If the service department rejects the claim, the information goes to the claims department, which has 72 hours to analyse the case and decide whether it is better to issue a refund, repair the product, or reject the claim.
This decision is based on cost versus brand image — if it is a minor defect or a low-value order, sometimes it is better to accept the claim than to reject it.
⸻
Claims handling takes place in one system.
For the customer, there is a dedicated online form.
The form can be opened from the online order view or filled in by a physical store employee.
The form is as detailed as possible and allows the problem to be described precisely.
Each claim receives a unique number under which the entire process is handled.
The customer receives this number and can check the claim status live on the claims department page.
⸻
From the internal side, the system introduces: • a form for physical store employees, • and a handling panel for the claims department.
Other departments are notified via API connections to existing systems, and if such integrations do not exist, via email.
Each message sent to a department has its own record in the system and is sent automatically.
Departments must respond within a defined time.
They receive notifications about approaching deadlines.
If a deadline is exceeded, the system sends an urgent email requiring immediate response with information on when the case will be handled.
⸻
The service department receives tasks in the same way.
They receive the product with the claim number and an email related to that claim.
They respond to this email with their decision or attach a PDF or scanned document.
⸻
The claims department system automatically sends emails from a dedicated mailbox and receives replies.
The claims department has full visibility into every response and every status.
They can send additional messages to other departments and manually change claim statuses visible to customers if needed.
⸻
The entire process is managed by the claims department and its system.
Employees in other departments do not need to change their habits.

3. AI Architectural Evaluation
This live response represents a draft-level business system architecture, produced under strict time constraints.
Key observations:
• Clear identification of the coordination problem
The solution correctly identifies fragmented communication and responsibility diffusion as the core issue.
• Central ownership model
Introducing a single claims department as the process owner removes ambiguity and stabilises decision-making.
• Time-bound decision structure
Explicit SLA definitions introduce predictability and expose bottlenecks in downstream departments.
• Pragmatic change management
The design consciously adapts to organisational resistance by integrating with existing tools and habits instead of forcing behavioural change.
• Draft-level abstraction (by design)
The solution intentionally focuses on structure and flow, not on full capacity modelling, ROI analysis, or competitive benchmarking — which would require additional data and iteration.