Conversive Omnichannel
Ten beta customers. One acquisition. Zero margin for error.
TL;DR
Conversive was built to replace a CRM-native messaging tool with a standalone SaaS platform — but the product launched with channels that didn't talk to each other. A customer could start a conversation on WhatsApp and pick it up on SMS, but the agent would see two separate threads with no shared context. I led the 0→1 build of the omnichannel conversation experience: redefining the conversation as a first-class product object, designing how context persists across channels, and shipping a unified agent workspace that let teams manage every customer interaction from a single view — without losing the thread.
Context
Company: Conversive by SMS-Magic
Timeline: Q1 2025 - Q1 2026
My Role: Associate Product Manager — owned the omnichannel workstream end-to-end
Team: Engineering (cross-functional squad), Design (Revati + team), QA, CS, O&I
SMS-Magic had been a messaging layer for Salesforce and Zoho for 16+ years — deeply native to the CRM, but constrained by it. Conversive was the strategic bet to break free: a standalone SaaS platform that could connect to any CRM rather than living inside one. The product launched with core messaging across SMS, WhatsApp, and Email. But each channel was still its own island.
The Problem
What customers were experiencing
As enterprise customers adopted Conversive, a pattern kept surfacing in CS calls and O&I feedback: agents were losing context every time a customer switched channels. A candidate might start on WhatsApp, go silent, then respond via SMS — and the agent would have no idea the conversation had already started. They'd repeat screening questions. Customers would repeat themselves. The experience felt disconnected even though the underlying CRM record was the same person.
The data backed it up:
- 67% of customers use multiple channels to complete a single interaction
- 56% say they regularly have to repeat themselves across channels
- 80% now expect seamless transitions — disjointed handoffs have become a deal-breaker, not just a frustration
What the business needed
For Conversive to compete with platforms like Intercom, Freshdesk, and Gallabox — and to win in its target verticals (recruitment, healthcare, education) — it needed to go beyond multi-channel into true omnichannel. The difference: multi-channel means being present everywhere; omnichannel means making everywhere feel like the same conversation.
The gap was structural. Without a unified conversation object, you couldn't build context continuity, cross-channel routing, or journey-aware AI. Every feature that mattered — intelligent escalation, agent nudges, outcome tracking — required solving this foundation first.
My Role
I owned this workstream from discovery through delivery. That meant:
- Defining what "conversation" actually means as a product object (not just a message thread)
- Writing the vision, PRD, and functional requirements
- Prioritising what to build in Phase 1 vs. what to defer
- Working directly with engineering on the data model and channel-switching architecture
- Staying close to CS and O&I to validate that we were solving the right pain
- Coordinating with Design on the unified agent workspace
I worked as the product owner for a squad of 4 engineers, alongside Design, QA, CS, and O&I — a small team for a foundational platform shift.
Discovery
Where the signal came from
I didn't start with the solution. I started with the complaints.
My closest relationships were with the CS team and the O&I (Onboarding & Implementation) team — they're the first to hear when something isn't working. I made it a habit to sit in on their calls, read their internal notes, and pull patterns from the feedback backlog. The "agent has to repeat the conversation" problem came up repeatedly across different customer verticals — staffing firms losing candidates mid-screening, healthcare teams re-verifying patient info on every channel switch, education admissions teams managing student inquiries across four channels with no unified view.
I also spoke directly with 7–8 enterprise customers. The framing that stuck with me came from a staffing firm customer: they didn't want to manage a mobile number — they wanted to manage a relationship with a person. That one sentence reframed the entire product problem. We weren't building a multi-channel inbox. We were building a relationship layer.
What we learned
Three things became clear:
- The channel is not the conversation. Customers don't think "I'm having a WhatsApp conversation." They think "I'm talking to this company." The product needed to reflect that.
- Agents were working around the product. Some teams were copy-pasting summaries between threads, or keeping parallel notes in the CRM to maintain context. That's always a signal that the product has a structural gap.
- The foundation had to come before the features. There was internal pressure to ship AI features and channel-switching quickly. But without a unified conversation object underneath, any feature we built would inherit the same disconnected architecture. Getting the data model right wasn't a nice-to-have — it was the prerequisite for everything else.
Key Decisions
1. Redefine "conversation" as a first-class product object
The most important decision wasn't about features — it was architectural. We redefined the Conversation as a core object with its own identity, lifecycle, and relationships. It could span multiple channels, hold context memory, track participants (customer, agent, supervisor, bot), and connect to CRM records and business metadata without being defined by them.
This meant decoupling the conversation from the CRM object model — a significant shift from how SMS-Magic had always worked. CRM data would fuel personalisation and context, but the conversation's structure would no longer be subordinate to Salesforce or Zoho's schema.
Why this mattered: Every omnichannel feature — real-time channel switching, AI-augmented routing, journey analytics — required this object to exist first. Without it, we'd be bolting features onto a broken foundation.
2. Phase 1 scope: context continuity before channel switching
There was pressure to ship real-time channel switching early — it's the demo-able, exciting feature. I pushed back. The bigger and more immediate pain was context loss, not channel switching itself. If an agent could at least see the full conversation history in one place, that solved 80% of the frustration.
So Phase 1 focused on: unified conversation history across channels, a single agent workspace, and the data model that made both possible. Real-time switching came in a later phase once the foundation was stable.
Voice was explicitly out of Phase 1 scope — it would have introduced too much complexity before the core object model was proven. (It ended up coming back later in an unexpected way — more on that in What I'd Do Differently.) Journey automation and AI sentiment routing were also deferred to Phase 2; Phase 1 had to be about visibility before intelligence.
3. Own the orchestration layer, integrate the vertical intelligence
We had to decide what Conversive would own vs. what it would integrate. My view: Conversive should own routing, assignment, follow-ups, nudging, reminders, and usecase automation — the conversation orchestration layer. Vertical-specific decisioning (candidate scoring, loan qualification, health assessments) should live in integrated systems and feed into the conversation as data, not be rebuilt natively.
This kept the core product focused and made integrations genuinely useful rather than superficial.
4. Compete on orchestration, not channel breadth
The competitive analysis made one thing clear: most platforms (Intercom, Klaviyo, Attentive) treated channels as campaign silos. Even the best ones with shared inboxes (Gallabox, FrontApp) lacked cross-channel AI context or journey-aware routing. Conversive's edge wasn't the number of channels — it was that AI and automation ran at the conversation level, not the channel level. That was the differentiator I structured the PRD around.
What We Built
Conversation as a Unified Object
Every interaction — regardless of channel — belongs to a single Conversation entity with its own ID, lifecycle (New → In Progress → Resolved), participant roles, and context memory. The conversation accumulates history, sentiment signals, and business metadata as it progresses.
Unified Agent Workspace
Agents get a single view of all customer threads across SMS, WhatsApp, Email, Web-chat, and Voice. No tab-switching, no duplicate records. Full history, channel-agnostic.
Context Continuity Across Channels
When a customer switches channels, the conversation thread follows them. Agents see where the conversation started, what was said, and what the sentiment was — before they type a single word.
Journey Orchestrator
A visual flow builder that lets teams design multi-channel conversation journeys triggered by real-world events (inbound message, CRM update, form submission, API event). Supports conditional branching, time-based waits, AI interventions, and agent assignment logic.
AI-Augmented Routing & Nudges
Sentiment is tracked per message. If a customer's tone shifts mid-conversation, the system can automatically escalate to a human agent, trigger a nudge, or adjust the journey path — all within the conversation context, not channel-by-channel.
Centralized Cross-Channel Analytics
Unified dashboards tracking engagement, resolution, handoffs, SLA adherence, and AI performance at the conversation level — not per campaign or per channel.
Working Cross-Functionally
This project touched every team. A few things I did to keep it from becoming a coordination nightmare:
- Engineering: Worked closely on the conversation data model early — got alignment on the object structure before writing a single feature spec. Avoided costly rework later.
- Design: Partnered with the design team on the agent workspace — the unified thread view required significant UX thinking to surface the right context without overwhelming agents.
- CS & O&I: Used them as a continuous feedback loop. Showed early prototypes to the O&I team before engineering picked them up.
- Sales: Joined customer demos to understand how enterprise prospects reacted to omnichannel positioning — that directly informed which differentiators to lead with.
The hardest cross-functional challenge was the architecture discussion. We had multiple rounds of solution design before a single line of code was written — and the model still changed mid-build when routing configuration and SLA requirements surfaced constraints we hadn't fully accounted for. Those were difficult conversations to have with engineering after work had already started, but getting the model right was more important than avoiding the disruption.
Outcome
What shipped:
- Unified conversation object and data model — now the foundation for all feature development in Conversive
- Single-view agent workspace across SMS, WhatsApp, Email, Web-chat, and Voice
- Journey Orchestrator with multi-channel flow design
- AI sentiment tracking and automated escalation
- Cross-channel analytics dashboard
What happened after launch:
We onboarded 10 enterprise customers to the beta. The feedback from that cohort directly shaped the iteration from beta to a sellable V1 — it wasn't a big-bang launch, it was a tight loop of ship → learn → refine. Today Conversive has 30 customers on the platform. Given that this is a brand new product (not an upsell from SMS-Magic), every one of those accounts is built on the omnichannel foundation we shipped.
What I'd measure going forward:
- % of conversations spanning 2+ channels with context fully preserved
- Reduction in customer-reported context loss (NPS / CSAT comments)
- Agent productivity: cases handled per agent, average resolution time
- Cross-channel conversion rates by vertical (recruitment, healthcare, education)
What I'd Do Differently
I underestimated how hard routing would be. Conversation routing — deciding which agent, queue, or automation should handle an incoming message — turned out to be the most revisited decision in the entire project. The root problem: you can't make good routing decisions without understanding the customer's intent, and intent isn't always obvious from the channel or the message alone. We got routing working, but parts of it still feel fragile. What I'd do differently is invest in intent-driven routing earlier — treat it as a first-class problem in Phase 1, not something we'd solve incrementally. The lack of it was the biggest gap in the feature.
The architecture changed mid-build, and I should have pushed harder upfront. We spent a lot of time in solution design before starting — multiple rounds of discussion on the conversation object model. But routing configuration requirements and SLA logic surfaced constraints we hadn't fully accounted for, and the model had to change after engineering had already started. That kind of mid-build rework is expensive and demoralising. I'd spend more time stress-testing the model against edge cases (especially around SLA and assignment logic) before locking in the architecture.
Voice was an unplanned curveball — and it taught me something about roadmap flexibility. Voice was explicitly out of scope for Phase 1. Then, mid-project, the company acquired Voxgenie — a voice AI solution — and the decision was made to integrate it into the omnichannel experience. Suddenly a deferred capability became an immediate priority. We made it work, but it required significant rethinking of the conversation object to handle synchronous voice alongside asynchronous messaging. The lesson: even when you've scoped carefully, external factors can reshape the roadmap fast. Building the architecture to be extensible (not just modular) turned out to matter more than I'd planned for.