Zorvia
21 April, 2026
Zorvia is where businesses connect every customer channel into one workspace.
Zorvia helps businesses link multiple social accounts into one place so they can communicate with customers without jumping between apps.
B2B
SAAS
CRM
Multi-Product Ecosystem
Chat is the backbone, but it doesn’t stop there. Teams can also run lightweight workflows, such as creating and sending invoices, and connect a chatbot integration that uses the Apex API so a bot can manage a crypto account and execute trading actions on behalf of the business.
Zorvia started after we launched Basewallet. The goal was to make each product stand on its own, with Zorvia becoming the third product in the lineup.
One workspace for channels, conversations, and team workflow.
My role
I worked on Zorvia in the same capacity as the other products, managing the complete product design for the core web workspace, the companion mobile experience, and the bot interface.
My work began with laying the foundation for the product, which included:
Defined IA for Channels → Inbox → Contacts → Team → Billing
Establishing the visual language and component patterns
What makes Zorvia, Zorvia
The problem Zorvia exists to solve
Most businesses don’t have a “messaging problem”. They have a fragmentation problem.
Customer conversations live across multiple social apps, and the cost shows up in small, painful ways: missed messages, duplicate replies, unclear ownership, and managers having no idea what’s actually happening day to day.
Zorvia exists to turn that chaos into one reliable workspace. Chat stays central, but the workspace is built to support real business workflows too, like sending invoices, and automation through a chatbot layer when teams need it.
The principles that keep it coherent
Once you centralise channels, add teams, and introduce automation, the main risk isn’t missing features. It’s losing coherence. So I leaned on three principles to keep Zorvia understandable, even as the surface area expanded.
One workspace, many channels
Zorvia treats channels as inputs to a single shared workspace. The goal is simple: no matter where a customer messages from, the team has one place to read, reply, and stay aligned.
All customer conversations, in one place — no matter where they start.
Team clarity
A unified inbox only works when ownership is obvious. Zorvia is designed around clarity of responsibility: assignments, conversation states, and team structure. It should be clear who is handling what, what’s waiting, and what’s already resolved.
Everyone knows what’s assigned, what’s waiting, and what’s done.
Automation as an extension of chat
Automation shouldn’t feel like a separate product. The chatbot integration exists because some businesses want to do real work inside a conversation, not copy and paste between tools. By connecting the Apex API, teams can enable bot-driven crypto account actions and trading flows through a chat surface that customers already use.
Zorvia stays honest about what’s happening: actions are explicit, confirmations are clear, and users never have to wonder whether the bot actually did it.
Context and why Zorvia existed
Zorvia started as a response to how businesses actually talk to customers
Many businesses don’t have a single “customer support channel”. They have WhatsApp, Telegram, Instagram DMs, maybe a website chat widget, and sometimes a phone number being shared around like a secret. That reality creates a quiet operational mess. Messages get missed. Two people reply to the same customer. Nobody knows who owns what. And when a manager asks for an update, the answer is usually somewhere between “let me check” and “it’s in my other phone”.
Zorvia exists to remove that fragmentation. It gives teams one place to connect channels, handle conversations, and build reliable habits around response, ownership, and follow-through.
Why did it become its own product?
Zorvia started after we launched Basewallet, as part of a broader push to have each product exist independently. Instead of bundling everything into one product, the goal was to let each one have a clear job, its own audience, and its own roadmap. That’s what made Zorvia worth building properly: it wasn’t a side feature. It was a complete workspace for businesses.
Why “chat, plus workflows” mattered
Centralising conversations is the foundation, but businesses don’t just reply to messages. They do work inside those conversations.
That’s why Zorvia also supports workflows such as invoice creation and sending, and why it includes a chatbot integration. For some businesses, the bot layer isn’t a gimmick; it’s a way to run actions through conversation, powered by the Apex API, without forcing customers into a separate interface.
Competitive landscape and the gap
A crowded space, with a familiar promise
Most tools in this space promise the same thing: “put all your customer conversations in one place”. And honestly, they’re not wrong. Shared inbox and customer messaging platforms have proven that centralising messages is valuable.
But when you zoom in on how many teams actually work day to day, the gap isn’t just “more channels”. The gap is operational clarity: who owns this conversation, what state is it in, and what’s the next action? Most products stop at ‘shared inbox’. Zorvia treats the inbox as the hub for ownership, workflow, and actions.
Where Zorvia deliberately leaned differently
I didn’t try to out-feature everyone. I focused on making Zorvia feel like a coherent workspace across three surfaces:
Web for structured team operations (channels, inbox triage, contacts, roles, billing)
Mobile for staying responsive on the go (lightweight actions, quick replies, notifications)
Bot for executing actions inside the same conversation context, powered by the Apex API
The bot layer matters because it turns chat from “conversation only” into “conversation plus action”. That’s a different promise from most shared inbox products, and it needs different trust and control patterns.
What I learned from competitors
Competitors helped confirm a few expectations that users bring into this category: setup needs to feel guided, states need to be explicit, and inbox ownership needs to be visible.
Where I was intentionally careful was avoiding the “feature drawer” outcome, copying every module just because it exists elsewhere. Zorvia’s story is stronger when it stays opinionated: chat first, workflows when needed, automation when it earns its place.
Money surface area and product boundaries
Zorvia isn’t “a crypto product”, but it does touch money through workflow and automation
Zorvia’s core job is customer communication. That’s the backbone.
But once you centralise customer conversations, you start touching the parts of the business that sit around money: invoices, payment follow-ups, account questions, and customers asking for actions that typically happen elsewhere.
So the design challenge wasn’t to turn Zorvia into a wallet. It was to support money adjacent workflows without losing the product’s identity notes.
What Zorvia owns
Zorvia owns the workspace layer:
connecting and managing channels
routing conversations into one inbox
team collaboration (assignment, status, internal coordination)
workflow tools like invoices
integrations that let businesses trigger actions from a conversation
What Zorvia does not own
Zorvia does not try to replace the systems underneath.
For anything that’s truly “account level”, like managing balances or executing trades, Zorvia sits above it as an interface layer. The source of truth remains the connected system.
That’s why the chatbot integration matters: it’s a controlled surface that uses the Apex API to run crypto account actions and trading, while keeping Zorvia’s role clear.
Why this separation mattered
This boundary is what keeps the product coherent.
It lets the inbox stay the centre, while still enabling powerful outcomes. Customers can ask for something in chat, a business can trigger the right action, and everyone stays in the same conversation context — without Zorvia pretending it owns the entire financial stack.
What I learned from users
The real problem wasn’t messaging. It was fragmentation.
Teams weren’t struggling to type replies. They were struggling to keep up with conversations spread across different apps, devices, and people.
That fragmentation created predictable pain:
Messages get missed, especially when volume spikes
Two people reply to the same customer, because ownership isn’t obvious
Managers can’t see what’s happening without asking someone to “check”
New team members take too long to ramp up, because history and context live everywhere
What “good” looked like
When I mapped what users actually wanted, it came down to a few simple outcomes. They tried to scan, know what matters, and act without second-guessing. They wanted a system where responsibility is clear and where every conversation feels like it has a home.
It also came from internal stakeholder interviews + reviewing how teams handled messages across devices/channels.
That’s what guided the big product decisions: a unified inbox with assignment and states, a contacts layer that carries context forward, team roles that prevent accidental chaos, and a mobile companion that keeps the team responsive without rebuilding the whole workspace.
Channels and Integrations
Channels are how Zorvia earns the right to exist
Zorvia only works if connecting channels feels straightforward and reliable. If the setup is confusing, teams never reach the inbox value. So I treated Channels and Integrations as one mental model: connect once, verify it’s working, then everything flows into the same workspace.
Channel hub
Channels are presented as a growing list, not a one-time configuration screen. That matters because businesses don’t connect everything on day one. The hub makes it obvious what’s already connected, what needs attention, and what’s available next.
Connection states
State is a product feature here. “Connected” isn’t just a label; it’s reassurance. I leaned on clear, consistent states so teams can trust what they’re seeing:
connected when a channel is live
pending when the setup isn’t finished
disconnected when something breaks or expires
coming soon for future channels (so the roadmap doesn’t feel like a promise)
Setup experience
Setup is designed as a guided path: pick a channel, follow the steps, then land back in Zorvia with confidence that messages will appear where expected. Where subscription is required, the experience stays honest: you should understand what you’re paying for before you connect anything.
Managing channels
Once a channel is connected, management should feel safe. Editing basic details is easy, but destructive actions (such as disconnect or delete) should be protected by guardrails. It should be hard to break production messaging accidentally.
API channel
The API channel is where Zorvia becomes extensible. Instead of treating it like a dev-only corner, I made it feel like a first-class channel with the basics businesses need: keys, documentation, and clear guidance on what it unlocks.
Inbox and conversation handling
The inbox is the product
If Channels is how Zorvia connects to the world, the inbox is where Zorvia proves its value.
The goal is simple: no matter where a customer messages from, the team should be able to pick it up, understand context quickly, and respond without confusion about ownership.
Two inboxes, two jobs
Zorvia separates the work into two clear spaces. The Contact Inbox is for external customer conversations. The Team Inbox is for internal coordination, so collaboration doesn’t leak into customer threads or get lost in side chats. That split keeps the mental model clean: customers in one place, team chatter in another.
Triage that doesn’t feel like admin
Most inbox tools fall apart when volume increases. People stop replying because the inbox stops making sense. So triage is built around a few predictable levers: filters, sorting, and conversation status. The idea is that you can scan fast, then get specific only when you need to.
Assignment and ownership
A shared inbox only works when responsibility is obvious. I designed the workflow so that assigning a conversation is quick, visible, and reversible. When someone owns a thread, it should look owned. When it’s unassigned, it should look like an opportunity, not a mystery.
Ownership is visible at a glance, not buried in menus.
Conversation lifecycle
Conversations naturally move through a rhythm: active, paused, resolved. Zorvia supports that with clear states like open, closed, and snoozed. These aren’t just labels; they’re how teams keep the inbox from becoming a permanent pile.
Reply to experience and internal notes
Responding to a customer should stay fast, but teams still need space to collaborate. So I treated internal notes and comments as first class, without letting them interfere with the customer reply flow. The goal is to keep context close, while keeping the customer experience clean.
Contacts, teams, and context
Customer context that doesn’t get lost in the inbox
A unified inbox only works when the team can quickly answer, “Who is this person, and what’s our history with them?” So, Contacts acts as the workspace’s shared memory. It’s where customer identities across channels are organised into something the team can trust, even when conversations move fast.
Contacts give the team a stable view of the customer beyond one thread.
Clear ownership through roles and teams
As soon as more than one person is replying, collaboration needs structure. So I treated teams and access control as a foundation, not a setting afterthought. Roles make it clear who can manage channels, change billing, invite members, or export data, and teams/groups help organise responsibility without turning every decision into a manager ping.
Teams and roles make responsibility and permissions obvious as the workspace scales.
Billing, automation, and the “actions” layer
Monetisation that sits close to the setup
Billing isn’t a separate admin corner in Zorvia. It sits close to integrations because that’s where the value becomes real: you connect a channel, your team starts replying, and the workspace becomes operational.
So I designed billing to feel like part of the same journey, with plan information, payment method management, and history kept transparent and predictable.
Plans, payment methods, and history are easy to find when a business is ready to scale.
Automation via the Apex API
The bot surface exists because some businesses want to do more than reply. They want to trigger actions inside the same conversation context. By connecting to the Apex API, Zorvia enables a chatbot to manage a crypto account and execute trading actions for the business, without forcing users to use a separate interface.
Automation lives where the customer already is: inside chat.
Trust and control for high-stakes actions
When money is involved, the UX can’t rely on “it probably worked”.
So I treated bot actions as explicit intent: clear commands, clear confirmations, and clear feedback. And on the workspace side, roles and permissions matter even more; the right people should be able to enable, manage, and monitor automation without making the whole team nervous.
Companion mobile app and cross-platform consistency
Mobile is for staying responsive, not rebuilding the whole workspace
The mobile app isn’t meant to replace the web workspace. It’s a companion for moments when teams are away from their desks but still need to stay on top of conversations.
So the focus is on the essentials: seeing what needs attention, replying quickly, and taking lightweight actions like assigning, snoozing, closing, or blocking, without losing context.
Mobile keeps the team responsive when they’re not at a desk.
Consistency that protects speed
When people switch between web and mobile, they shouldn’t have to relearn the product. So I kept the core language and interaction patterns consistent: the same conversation states, the same idea of ownership, the same status styling, and the same rhythm of “scan → open → act”. It’s less about matching pixels and more about matching mental models.
A shared system, used lightly
I treated design consistency as a quiet tool, not a loud showcase. Tables, badges, status pills, empty states, and action placement follow the same rules across the workspace. That keeps Zorvia feeling like one product across web, mobile, and the bot surface, even though the surfaces behave differently.
Impact & learnings
What success looked like
For Zorvia, success wasn’t “more features”. It was whether the workspace actually reduced fragmentation and made teams faster and more confident.
I focused on practical signals that really matter! It was exciting to see how quickly teams could set up and respond once channels were connected. Keeping ownership clear while teamwork flourished was a priority. The onboarding journey felt so much more engaging with clear connection states. We also minimised bot action risks by ensuring explicit intent and confirmations. It’s all about making the process smooth and positive for everyone involved!
What shipped
The core experience shipped as a coherent workspace across three surfaces.
On the web, teams can connect channels, manage conversations, organise contacts, set up team roles, and handle billing. On mobile, teams can stay responsive with lightweight inbox actions and notifications. And through the bot surface, businesses can trigger “actions inside chat” via the Apex API when automation is needed.
Learnings
The most significant learning was that coherence is a product feature.
When a product has multiple surfaces (web, mobile, bot) and various jobs (chat, invoices, automation), the winning move isn’t adding more modules. It’s keeping the mental model stable so users always know where they are, what’s happening, and what to do next.
I also learned that high stakes automation needs stronger UX honesty. If money actions can be triggered through chat, confirmation, and feedback, they can’t be vague. The product has to be explicit about intent, state, and outcome.
What I’d do next
Next, I’d go deeper into three areas.
First, I’d sharpen reporting so managers can see workload, response quality, and bottlenecks without manual checks. Then I’d expand automation controls so businesses can manage who can enable bots, what actions are allowed, and what audits are kept. And finally, I’ll improve onboarding so connecting channels and inviting teams feels even more guided for first-time users.
Read Case Studies
