build.allanninal.dev

Part 5 of 7 · Social inbox unifier series ~5 min read

How a DM gets answered

The thread is in Sam’s queue at the top, labeled shipping · urgent, with the order number highlighted and the full back-and-forth on screen. What happens next? A person reads it and decides. This post walks through the three things a teammate can do on a thread — send a reply, reassign it, or close it — and how the customer’s platform, the queue, and the audit trail all stay in sync. The one thing the system never does is write or send the reply itself.

Key takeaways

  • Three actions per thread: send reply (human-written), reassign (hand to another teammate), close (mark done).
  • Every reply is typed by a person and goes back out through the same platform the customer used.
  • Templates can pre-fill an opening line, but the person edits and owns every word before sending.
  • Reassign moves the thread to a new queue and updates both teammates’ open-thread counts.
  • Every action writes an audit row — who did what, when — so a thread’s history is never a mystery.

Three actions on a thread

Three actions a teammate can take on a thread A diagram showing one input on the left flowing through the shared inbox, then branching into three action paths. Far left: a "Thread in shared inbox" box showing a typical view — the customer's message, the labels, the order or customer details, the full history — with three controls below: Send reply, Reassign, Close. The teammate picks one. The middle column shows the three branches. Branch one, Send reply: the teammate types the reply in their own words (optionally starting from a template for the topic, which they edit); on send, a Function URL Lambda posts the reply back out through the same platform the customer used — Instagram reply to an Instagram DM, WhatsApp reply to a WhatsApp message — and appends it to the thread. The system never writes or sends a reply on its own; a person writes every word. Branch two, Reassign: the teammate hands the thread to a different teammate or team, with an optional note on why; the thread moves to the new queue, both open-thread counts update, and the new owner sees it at the right urgency. Branch three, Close: the teammate marks the thread done; it leaves the active queue and the customer's history keeps it for next time; reopening is one click if the customer writes back. The right side shows the convergence: every action writes a row to the audit table with timestamp, thread id, action, by-user, and notes. A note at the bottom: every reply is human-written and goes back out on the customer's own platform — the system gathers and routes, a person answers. Thread in inbox message, labels, history [Send reply] [Reassign] [Close] Action 1 Send reply • Teammate types it, in their own words • Goes out on the same platform, appended Action 2 Reassign • Hand to another teammate, with a note • Both open-thread counts update Action 3 Close • Mark the thread done — leaves the queue • Reopen in one click if they write back Audit trail DynamoDB siu-audit timestamp · thread_id action · by-user notes Every reply is human-written and goes out on the customer’s own platform — a person answers.
Fig 5. Three actions per thread, three different effects. Send a human-written reply back out on the customer’s platform. Reassign to another teammate. Or close. Every action writes to the audit trail.

Action 1: send a reply (the most common)

Sam reads the thread, checks the order, and sees it shipped overnight. He types: “Good news — your order #4821 went out last night, here’s your tracking link. It should arrive Thursday, ahead of your trip. Safe travels!” He could have started from a shipping template that pre-fills the opening and the tracking-link placeholder, but he edited it to fit this customer and this moment. He hits Send.

The Send button submits to a Function URL Lambda. Two things happen, in order. First, the Lambda posts the reply back out through the same platform the customer used — an Instagram DM goes back as an Instagram reply, a WhatsApp message goes back as a WhatsApp reply — using that platform’s send API and the credentials in Secrets Manager. Second, the reply is appended to the thread so the next teammate to open it sees the full conversation, and an action: replied row is written to the audit table. The customer experiences a normal, on-brand reply on the app they already use. They never know there’s a unified inbox behind it.

The system writes none of those words. Templates can offer a starting point, but a person edits and owns every reply before it goes out. There is no “auto-reply” button, by design.

Action 2: reassign (the hand-off)

Sometimes the message landed with the right team but the wrong person, or it turns out to need someone else. The shipping question is actually a refund in disguise. The customer is a VIP the owner wants to handle personally. Sam is going off-shift and wants to hand a live thread to whoever’s taking over.

Reassign lets him pass the thread to another teammate or team, with an optional note on why (“customer is upset, please handle gently”). On save, the thread moves to the new owner’s queue at the right urgency, Sam’s open-thread count drops by one and the new owner’s rises by one (so the fair-load math from Part 4 stays accurate), and an action: reassigned row is written with both names. The customer sees nothing — no “you’re being transferred” message goes out unless a teammate chooses to send one. The hand-off is internal.

Action 3: close (the “done”)

When the conversation is finished — the question answered, the issue resolved — the teammate closes the thread. It leaves the active queue so nobody works it again, the owner’s open-thread count drops, and an action: closed row is written. The thread isn’t deleted: it stays in the customer’s history, so the next time that person messages you, whoever picks it up sees the whole past relationship.

Closing isn’t final in a scary way. If the customer writes back after a thread is closed — “actually, one more thing” — the new message’s fingerprint links to the same conversation, and the thread reopens in the queue automatically, with all its history intact. Nobody starts from scratch.

Every action is logged, every thread has a history

The audit table records every reply, reassign, and close with the teammate who did it, the timestamp, and a note. That trail is what makes a shared inbox trustworthy for a team. When a customer says “someone promised me a refund last week,” anyone can open the thread and see exactly who replied, what they said, and when. When a thread bounced between three people, the reassign notes explain why. The audit trail is the team’s shared memory — especially useful months later, or after the person who handled it has moved on.

And the rule holds at every step: the machine gathered the message, labeled it, routed it, and kept the record — but a human read it and a human answered it, in their own words, on the customer’s own platform.

Next post: the cost breakdown. The whole pipeline above runs in coffee-money territory at SMB volume; Part 6 explains exactly where the dollars go and why the only model call — the per-message label — stays cheap.

All posts