Connecting customers with suitable support agents.
Bridged is a full-stack, real-time customer-support chat platform. Customers complete a short triage process before entering a PostgreSQL-backed queue. The system then assigns an eligible agent, who can accept the chat and communicate with the customer in real time.
I designed and built the application from concept to deployment. The project brings together product thinking, user-flow design, backend architecture, frontend development, data modelling, real-time communication and cloud infrastructure.
PRODUCT DEMO
See the complete support flow in action.
The demo follows a customer through language and topic triage, automatic agent assignment and a live conversation, then shows how the application stores and updates the underlying data.
Route every customer quickly, suitably and fairly.
A useful routing experience has to balance several needs at once: understand the customer’s request, find an agent with the right language and skill, respect agents’ availability and capacity, distribute workload fairly, and respond appropriately to priority requests.
SUITABILITY
Match the need
Only agents with the required language and topic proficiency should be considered.
FAIRNESS
Share the workload
The most proficient eligible agent should not automatically receive every conversation.
URGENCY
Respect priority
Higher-priority chats need earlier target assignment times without creating a rigid queue.
RELIABILITY
Protect capacity
Concurrent assignment attempts must not select the same chat or over-allocate an agent.
CUSTOMER JOURNEY
From requesting help to resolving a conversation.
I mapped the end-to-end journey before implementation so that product behaviour, system states and technical responsibilities followed the same flow.
01
Request help
The customer starts a new support conversation.
02
Select language
A language triage step captures the communication requirement.
03
Identify topic
The support topic determines the skill needed from an agent.
04
Join the queue
The chat is persisted with its priority and assignment deadline.
05
Get assigned
An eligible agent is selected and accepts the conversation.
06
Chat in real time
Customer, agent and bot messages are stored and delivered live.
07
Close the chat
The conversation ends and the agent’s available capacity is restored.
PRODUCT DECISIONS
Turning routing requirements into clear system rules.
TRIAGE
Separate language from topic
Customers answer one question at a time: which language they need and what their enquiry is about. The system stores these as two distinct criteria, allowing it to match agents by both language proficiency and topic skill.
ELIGIBILITY
Filter before ranking
The system first filters agents by language, skill, availability and remaining capacity, then ranks only those who are eligible.
FAIRNESS
Workload before proficiency
Ranking only by proficiency would repeatedly favour the most skilled agents. Open-chat count is considered first, followed by proficiency.
PRIORITY
Use assignment deadlines
I replaced a fixed weighted-priority approach with target assignment times, allowing the most urgent deadline to be considered first.
ARCHITECTURE & IMPLEMENTATION
A modular monolith supporting the complete experience.
I chose a modular monolith: one deployable Spring Boot application organised into distinct modules for customer triage, assignment, chat lifecycle and messaging. This kept the MVP simpler to develop, test and deploy while maintaining clear boundaries between responsibilities.
I first built the backend, including the data model, REST APIs, assignment logic and real-time messaging. I then used AI coding tools to build the React frontend around these existing APIs and customer-agent flows.
INTERFACEReact + ViteCustomer and agent experiences
REST STOMP
APPLICATIONSpring BootAPI, scheduler and assignment rules
JPA
DATAPostgreSQLChats, messages, agents and skills
DEPLOY
INFRASTRUCTUREAWSEC2, RDS and Nginx
ASSIGNMENT LOGIC
Selecting an agent without sacrificing fairness or consistency.
Queued chatReady for assignment
→
FilterLanguage, skill, availability, capacity
→
RankWorkload, then proficiency
→
ProtectTransaction, locking and SKIP LOCKED
→
AssignAgent accepts the chat
TECHNICAL CHALLENGES
Solving the technical challenges behind the MVP.
END-TO-END DEVELOPMENT
Connecting every layer
Spring Boot, WebSockets and AWS deployment were new to me. Building Bridged helped me understand how the frontend, API, database, real-time messaging and cloud infrastructure operate as one system.
ASSIGNMENT ALGORITHM
Balancing suitability, workload and priority
The first algorithm ranked agents mainly by proficiency, which could repeatedly direct work to the most proficient agents. I introduced open-chat counts and maximum capacity, then ranked eligible agents by workload before proficiency. After researching how other support systems use service-level targets, I also applied a simplified approach in which each priority level receives a target assignment time and the most urgent deadline is considered first.
CONCURRENCY
Protecting shared state without losing queued chats
To prevent concurrent assignment attempts from selecting the same chat or exceeding an agent’s capacity, I wrapped the assignment process in a database transaction and used pessimistic row locking with PostgreSQL’s SKIP LOCKED. A locked chat is skipped temporarily rather than blocking the process, while the scheduled assignment job continues checking unassigned chats on subsequent runs so they remain visible and are considered again.
DEPLOYED ENVIRONMENT
Handling data and time consistently
Local and RDS databases generated independent IDs, while Singapore and UTC server time caused messages to appear out of order. I aligned the MVP server timezone; a future version will use Instant or OffsetDateTime.
COMPLETED & PLANNED DEVELOPMENT
Tracking the delivered MVP and the path to production readiness.
I translated the delivered system and planned improvements into epics, user stories and implementation tasks with acceptance criteria. The board makes the current product state visible: completed MVP capabilities sit alongside the work needed to make Bridged more secure, resilient and observable.
Product backlog snapshot showing completed MVP work and planned production improvements.
COMPLETED MVP
Delivered in the MVP
Guided customers through language and support-topic triage
Automatically assigned customers by priority, agent eligibility, capacity and workload
Enabled persistent, real-time messaging between customers and agents
Supported chat acceptance, closure and automatic capacity updates
Deployed the complete application on AWS
PLANNED DEVELOPMENT
Planned next steps
Restore active conversations after browser refresh and prevent duplicate chats
Secure the platform with authentication and role-based access
Trigger assignment through customer and agent lifecycle events
Classify support topics from customers’ free-text requests using AI, with a confidence-based fallback
Define fallback and escalation rules for priority chats when no eligible agent is available
Add automated tests for agent assignment, chat-state transitions and concurrent assignment attempts
Standardise time handling in UTC and optimise assignment queries
Monitor waiting times, agent workload and assignment targets through an operations dashboard
Build for today’s needs while leaving room to evolve.
Bridged gave me hands-on experience across the complete software-development lifecycle and showed me that a reliable support experience depends on both the interface and the system behind it. Designing the assignment process meant considering not only how to select an eligible agent, but also how to retry, fall back or escalate when no agent is available, especially for priority chats. The broader lesson was to match technical decisions to demonstrated needs: the modular monolith and PostgreSQL-backed queue are appropriate for the MVP, while additional infrastructure such as a dedicated message queue should only be introduced when usage and performance data justify the added complexity.
