Business Messenger
Operational Communication Layer
Messaging where a conversation is attached to a document — an order, a tour, a bill — rather than floating free.
- TYPE
- COMMUNICATION
- STATUS
- R&D
- YEAR
- —
- ROLE
- Architecture, prototype
- PLATFORM
- Flutter client, Node.js realtime service
- STACK
- Flutter · Node.js · WebSocket · PostgreSQL · Redis
PROBLEM
Operational coordination happens on consumer messaging apps: approvals, rate confirmations, delivery instructions and disputes, all in a scroll that belongs to whoever owns the phone. When staff change, the history walks out.
The information is also disconnected from the operation. A message approving a discount is in one place and the bill it approved is in another, with nothing linking them.
SYSTEM
Threads are anchored to a record in a business system. A conversation about a purchase order lives on that order, is visible to whoever has permission to see the order, and survives the person who started it.
Approvals are first-class messages: a request carries the document and the action, and accepting it performs the action rather than merely saying yes.
CORE FLOW
How the operation moves through the system.
- Rate confirmation and change requests on the order itself
- Driver instructions and exception reporting against the trip
- Discount and credit approval attached to the document
- Operational issue with the record that caused it
- AUDIT TRAIL
- APPROVALS
- NOTIFICATIONS
Orders, tours, bills and tickets each anchor conversation threads in a shared thread service, which produces an audit trail, approvals and notifications.
KEY MODULES
- M01Anchored threads
- A conversation belongs to a document, not to a person phone.
- M02Inherited permission
- Thread visibility follows access to the anchored record.
- M03Actionable approvals
- Accepting a request performs the operation and records who approved it.
- M04Presence & delivery
- Realtime transport with offline queueing and read state.
ARCHITECTURE
- Transport
- WebSocket service with Redis for fan-out and presence.
- Permission
- Derived from the anchored document, evaluated per request.
- Storage
- PostgreSQL; messages are append-only and part of the document audit trail.
- Status
- Prototype. Being validated inside existing products before productisation.
ENGINEERING
The parts that were not obvious, and what the system does about them.
- 01 / 02
Permission that changes under a live thread
If access to a document is revoked, the conversation about it has to follow. Evaluating visibility per request rather than caching membership is slower and correct.
- 02 / 02
Approval as an action, not a sentence
The value is in a yes that actually posts the discount. That means the message layer needs a safe, idempotent way to invoke a domain operation, and a clear record of what it did.
SCREENS
- SCREEN_01Thread anchored to a purchase order
- SCREEN_02Approval request with document context
RESULT
Early stage. The useful finding so far is that the anchor matters more than the messaging: once a thread belongs to a record, most of the chaos of operational chat disappears.