Live Chat

Paid pluginsize Mplanned, not built

Indicative price, not an offer: €34/mo; visitor tracking, chat routing, canned responses

Generated from docs/plan/paid/live-chat/PLAN.md in the AstroBaaS repository. Nothing described below is implemented — it is the written plan for it.

Merchants need live chat to convert abandoning visitors: real-time messaging, visitor tracking, chat routing to available staff, and message history. This feature provides a complete chat engine with operator presence and chat transcripts.

The problem

My site visitors leave without talking to anyone. Live chat converts 20% better than email, but I have no system to handle real-time conversations or see when someone is available.

What it does

• Visitor tracking: anonymous visitor ID (cookie/localStorage), tracked across page views, visible to operators
• Chat initiation: visitor clicks ‘Chat’ button, conversation is created, assigned to next available operator
• Real-time messaging: WebSocket connection, messages sync bidirectionally, mark as read
• Chat routing: simple (first available) or round-robin (distribute evenly); prefer operators online/not-do-not-disturb
• Operator presence: online/away/do-not-disturb; visible to all operators; auto-away after 5 min inactivity
• Canned responses: pre-written quick replies (‘I can help with that’, ‘One moment…’) for fast response
• Chat history: message transcript stored per conversation, searchable by visitor/date, exportable
• Offline messaging: visitor submits a message when no operator is online; stored and shown to first operator who comes online
• Notifications: visitor sent offline message notification, operator notified of new chat in queue
• Admin dashboard: chat list (active/closed), visitor info (browser, referrer, pages visited), average response time, conversation metrics
• API endpoints: create chat, send message, get conversation, list chats, update operator presence

What it deliberately does NOT do

Each boundary carries its reason. A boundary without a reason gets crossed by the next person who reads this.

• Video/voice chat — real-time media streaming is a separate feature; text-only in v1
• Chatbot/AI responses — automatic replies are manual canned responses only; no NLP/ML
• Chat transfer to external services (e.g., WhatsApp, Facebook Messenger) — single-channel text in AstroBaaS
• Multi-language operator pools — operators speak the customer’s language; no translation layer
• Phone queue management or IVR — no telephony integration

Data model

New entity: Chat {id, visitor_id, assigned_operator_id (nullable), started_at, ended_at, status, visitor_email (nullable), visitor_name (nullable), referring_url, pages_visited (JSON array)}. New entity: ChatMessage {id, chat_id, sender_type (visitor/operator), sender_id, message_text, sent_at, read_at (nullable)}. New entity: OperatorPresence {id, operator_id, status (online/away/dnd), last_activity_at, current_chat_count}. New entity: CannedResponse {id, title, body, created_by_operator_id}. Schema migration across all three drivers.

API

• POST /api/chats — create new chat (anonymous visitor)
• GET /api/chats/:id — fetch chat detail and message history
• POST /api/chats/:id/messages — send message (visitor or operator)
• PATCH /api/chats/:id — update chat (assign operator, close chat)
• GET /api/chats — list active chats (operator only)
• POST /api/operator-presence — update operator status
• GET /api/operator-presence — list all operator statuses
• GET /api/canned-responses — list templates
• POST /api/admin/chat-metrics — dashboard stats (response time, active count)

Every route added here must also appear in src/pages/openapi.json.ts — a test fails the build if it does not.

Admin

Chat dashboard: list of active chats (visitor name, operator assigned, wait time). Click to open chat panel. Message history with timestamps. Visitor profile card: browser, referrer, pages visited, chat history with this visitor. Operator list sidebar: each operator’s status (online/away/dnd), current chat count, avg response time. Canned response library: browse/add/edit/delete templates. Metrics panel: current active chats, avg response time, chats/hour, offline message queue.

The seam — why this is paid

Core owns the chat entity model, message storage, routing logic, and REST API. Paid layer owns WebSocket real-time infrastructure (maintaining persistent connections, scaling to N concurrent chats), operator SLA tracking (response time guarantees, availability monitoring), and support for multi-operator workflows (shift management, escalation rules, performance analytics).

Support commitment: chat SLA, operator availability tracking, message history

Dependencies

• WebSocket server or real-time messaging infrastructure (not part of core; must be added or assumed)
• Visitor tracking/cookie system (assume browser-side localStorage + server-side session)
• Email system (already shipping in core) for offline message notifications
• Operator/staff entity (already shipped)

Acceptance checks

Each of these must be able to fail. Before claiming this is done, break the code deliberately and watch each one go red.

• A visitor can initiate a chat without authentication; a unique visitor_id is assigned and stored
• A chat is created and assigned to the first available (online, not-DND) operator
• An operator can send a message; it appears in real-time for the visitor (WebSocket)
• A visitor can send a message; it appears in real-time for the assigned operator
• An operator can change status from ‘online’ to ‘away’; new chats are not assigned until status returns to ‘online’
• A canned response can be selected and inserted into the message box
• If no operator is online, a visitor’s message is stored as ‘offline message’ and is shown when the first operator comes online
• Chat history is searchable by visitor name and date range; results include conversation text

Risks

WebSocket connections must be persistent and reconnect on network loss; dropping a chat mid-conversation is a data loss issue. Visitor IDs must be unique per browser; cookie spoofing or clearing cookies creates new visitor records (duplicate visitor detection is a separate feature). Operator presence state can become stale if operator browser closes without sending disconnect; timeout (5 min inactivity) mitigates. Offline messages can pile up if operators are offline for long; queue size limits and alerting are needed. Chat transcript export must exclude sensitive data (API keys, passwords) if operator types them; basic redaction is minimal.

Commercial context

The anchor is what the nearest equivalent charges on Shopify or Magento today. It is context for a pricing decision, not the decision.

---

Generated from the commerce plan. See docs/COMMERCE-PLAN.md for the full catalogue and ../../AI-GUIDE.md for how to work on this repository.