Customer messaging
A shared team inbox for WhatsApp with assignment, response deadlines, reply drafting and the platform messaging rules enforced in code.
Build effort, not elapsed calendar time. Engagements ran alongside study and employment, so this figure is the work itself rather than the span it sat in.
Interface built in code for this case study — not a client screen capture.
01Business problem
A large share of Indian businesses sell and support on WhatsApp from personal phones, which means the customer history belongs to whoever is holding the handset.
Who feels it
The pattern is everywhere: enquiries arrive on WhatsApp, two or three staff members answer from their own numbers, and the record of what was promised to a customer exists only in one person’s chat history. When that person is on leave, the conversation restarts. When they leave the company, it disappears.
There is no view of what is unanswered. An enquiry that arrives at 9pm sits unseen next to a personal message from a friend, and nobody can say how long a customer has been waiting. Ownership is implicit, so two people reply to the same customer or nobody does.
On top of that, the WhatsApp Business Platform has real rules — a business can only send free-form messages inside a window after the customer’s last message, and outside it must use pre-approved templates. Teams working from personal phones discover these rules by having messages fail, and a CRM that ignores them produces confident interfaces that quietly do not deliver.
02Product overview
A team inbox built on the WhatsApp Business Platform where every conversation belongs to a contact record, has an assigned owner and a response deadline, and where the platform’s messaging window rules are enforced by the composer rather than discovered through failures.
Engineering notes
Conversations are attached to contact records rather than phone handsets. A contact carries the full message history across staff, plus structured attributes — enquiry source, interest, order references, language preference — so context survives a change of owner. Assignment is explicit and every conversation has exactly one owner and a visible response deadline.
The composer knows the platform rules. Inside the customer service window it allows free-form replies; outside it, it switches to approved template selection with parameter fields and explains why. This single piece of logic removes the most common cause of a business message silently not arriving.
Language handling is the part generic inboxes get wrong. Customers write in English, Hindi, and Hinglish in Latin script, often within one message. Reply drafting works with the mixed-script reality rather than assuming a single language, and drafts are suggestions in the composer — an agent always sends.
03Key features
10 capabilities, of which 3 are model-backed. The rest are ordinary deterministic software, and the distinction is marked so the AI claim stays honest.
One queue of conversations with owner, status, last message and time waiting, so nothing depends on who is holding a phone.
Message history, structured attributes, order references and notes attached to a contact rather than a chat thread.
Explicit ownership with a deadline per conversation, and escalation when a first response has not gone out in time.
The composer allows free-form replies only inside the platform’s service window and requires approved templates outside it.
Suggested replies generated from the conversation and contact record, presented in the composer for an agent to edit and send.
Messages in English, Hindi and Hinglish are handled without assuming one language per conversation, including for drafting.
Incoming messages are tagged with an intent — price enquiry, order status, complaint, support — which drives routing and reporting.
Approved templates with parameter fields, approval status and category, so an agent cannot select a template that will be rejected.
Team-maintained canned responses with variables, because most questions in a messaging channel are the same twenty questions.
First response time, resolution time and intent mix by period — the numbers a manager needs to staff the channel.
04User flow
The path from the trigger to the finished record, with each step attributed to whoever performs it — a person or the system.
05Architecture
The processing path first, then the layers it runs on, then the constraints that shaped both.
Path through the system
Webhook intake with idempotency on provider message id.
Phone normalized to E.164, contact matched or created.
Intent and language detected, conversation attributes updated.
Owner assigned, response deadline set, escalation scheduled.
Draft offered; composer enforces window and template rules.
Delivery and read receipts folded into message state.
Layers
Why it is shaped this way
06Technical decisions
Every decision here was contested by a reasonable alternative. The trade-off column is the part usually left out.
Why
Status callbacks arrive out of order and can be redelivered. Ranking states and refusing backward transitions is the only reliable way to keep the thread honest about what the customer actually received.
Trade-off
A genuine regression — delivered then failed — needs an explicit exception in the ranking rather than being handled by the general rule.
Why
Every send decision depends on it, so computing it once per conversation and exposing it to the composer, the template picker and the scheduler avoids three implementations that can disagree.
Trade-off
The value is time-dependent, so it is recomputed on render and re-checked at send time. The interface can be a minute stale; the send path cannot be.
Why
The same customer messages from a number written five different ways across systems. Normalizing to E.164 at every boundary is what allows one contact record instead of five.
Trade-off
Numbers without a resolvable country code need a default region, which is configuration rather than inference.
Why
A large share of real messages are Latin-script Hindi mixed with English. Systems that force a single detected language produce drafts that read as wrong to the customer.
Trade-off
Automated intent tagging is less certain on mixed script, so intent is shown as an editable tag rather than a locked classification.
07Challenges
Not the setup work. These are the problems where the first implementation was wrong and had to be reconsidered.
Approach
Inbound events are deduplicated on provider message id before any write. Status transitions are applied through a rank comparison so only forward moves are accepted, and unknown statuses are logged rather than applied.
Outcome
Threads became a reliable record. A redelivered webhook is a no-op instead of a second bubble in the conversation.
Approach
The composer derives its mode from the window. Outside it, the free-form field is replaced by the template picker with an inline explanation and the parameter fields for the chosen template, and send is re-validated server-side.
Outcome
The failure mode disappeared from the agent’s experience, and template usage became a deliberate choice rather than a workaround.
Approach
An optimistic message is inserted with a queued state and a client-generated key, then reconciled when the provider id returns. Failures move to a failed state with a retry action rather than vanishing.
Outcome
The interface stays responsive while never showing a message as sent that the provider rejected.
08Business value
Stated qualitatively on purpose. Invented percentages are the easiest thing to put on a portfolio and the easiest thing to see through.
Operational effect
What would change at scale
09Interface
Dense operational views rather than dashboards. These are used for hours at a time, so the priorities are legibility, keyboard flow and state that is never ambiguous.
Team inbox
Conversations with owner, intent tag, last message and time waiting, with unanswered items surfaced first.
Conversation thread
Message history with per-message delivery state, contact panel alongside, and the drafted reply in the composer.
Window-aware composer
Free-form input inside the service window; template selection with parameter fields and a stated reason outside it.
Channel report
First response and resolution times with intent mix by period.
The screen above is built in HTML and CSS for this case study. It reproduces the layout, states and vocabulary of the real build without exposing client data, which is why it exists rather than a screenshot. It is evidence of design and of the decisions behind it. It is not a photograph of a deployed system, and no part of it is a capture of anyone else’s product.
10Technologies
Chosen for the shape of the problem, not for novelty. Anything unusual is justified in the decisions section above.
11Technical preview
There is no repository link on this site. What is available instead is the module structure, the data model, the interface contracts and annotated excerpts written for this case study — enough for a technical reviewer to judge the engineering.
Technical preview
Selected implementation details are available for technical review: component structure, data models, architecture notes and sanitized code excerpts. Some client-specific source material stays private because of confidentiality. Enter the project access keyword if you have been given one — the same one works across every case study.
A presentation convenience, not authentication. This is a static site, so the keyword ships to your browser with the page and anyone reading the bundle can find it — worth saying plainly rather than dressing it up. Nothing confidential is stored behind it.
Inside this section
For private client work, contact me for a walkthrough.
Next step
Send the process, the constraints and the deadline. You will get an honest scope, an architecture sketch and a timeline before any commitment.