Inside Relayvia: building a shared messaging workspace
A shared inbox needs more than a list of messages. Relayvia connects the customer, conversation owner, internal context and delivery state across WhatsApp and Instagram. Here are the implementation decisions behind that workflow.
The project at a glance
- The problem
- Teams need to know who owns a customer reply and what has already happened.
- What we built
- A shared WhatsApp and Instagram inbox with assignments, notes and delivery updates.
- How it helps
- Customer context and team coordination stay in the same workflow.
This is our own product build. Customer performance results have not been published.
The problem: every handoff needs context
When more than one person handles customer enquiries, a message history cannot explain everything. Someone needs to own the reply, a colleague needs to understand what is waiting, and the business needs to distinguish a drafted response from a delivered message.
Relayvia is an internal product build by IshvaniHub. This study describes its implementation rather than claiming customer performance results. The product uses Laravel and Livewire, connected to Meta’s messaging APIs.
The conversation workflow
- Incoming channel event
- Contact and conversation
- Owner, notes and status
- Queued reply
- Delivery update
The same conversation record connects the customer’s message to the assignment and subsequent reply. Channel-specific APIs remain behind the workspace workflow.
Keep customer identity beside the message
Relayvia records incoming messages against a contact and conversation. WhatsApp and Instagram have separate channel connections, while the inbox brings contact history and the next action into the same workflow. A channel selector keeps account context explicit when switching between connected accounts.
Separate ownership from conversation status
An assigned person answers who owns the next action. Open, pending and resolved describe where the conversation stands. These are separate values: a pending conversation can still have a clear owner. Internal notes preserve context without sending those notes to the customer.
Show reply activity separately
The conversation service maintains a short-lived reply activity record in the cache and broadcasts presence updates. This gives the interface a signal about another person replying. Presence is temporary coordination information; it is separate from durable assignment and is not a guarantee that simultaneous sends are impossible.
Keep the workspace boundary in data access
Tenant-aware models apply a workspace scope to ordinary authenticated user queries. Channel selection checks that an account belongs to the current workspace. Role and permission checks gate inbox routes and actions. Administrative and background processing paths need their own explicit context; a shared interface alone does not enforce isolation.
Keep delivery separate from the person’s click
Outbound messages are recorded before a queued sending job runs. Delivery webhooks then update status information. This separates a message being prepared or sent from delivery and read outcomes. The inbox can show those states rather than treating a successful button click as proof of delivery.
What this makes possible
The implementation supports assigning a conversation, leaving an internal note, changing its status, sending a reply and receiving delivery updates in one connected workflow. Campaigns, contact segments and reports build on the messaging and contact records.
The next review for a particular business is practical: connect eligible accounts, agree on ownership, exercise a handoff and check the resulting message states. Availability and setup requirements are confirmed during the product walkthrough.
Explore the product
Let’s talk
Tell us about your project
Share what you want to improve or build. We’ll reply by email to discuss your needs and a useful next step.