Chapter 3 of 44 min skim · expand any section for the full story

Fixing onboarding earned me this workstream.

Building the conversation object that became Conversive's platform foundation

0→30 enterprise customers in 7 months, built on the data model I spec'd.

0→1 BuildOmnichannelB2B SaaSAI Routing

0→30

Enterprise customers

7 mo

Build to platform foundation

Engineer squad

Conversive product screens showing inbox, automations, contacts, and analytics

A slice of the Conversive product: inbox, automations, contacts, and analytics.

Conversive shipped with channels that didn't talk to each other. An agent could lose a candidate mid-screening just from a channel switch. I led the 0→1 build of the conversation object that fixed it: one unified thread across channels, with a single agent workspace to match.

✦

Context

CompanyConversive by SMS-Magic

TimelineJanuary – July 2025

RoleAssociate PM (owned the omnichannel workstream end-to-end)

Team

Engineering ×4DesignQACSO&I

SMS-Magic had been a CRM-native messaging layer for 16+ years. Conversive was the bet to break free: live with SMS, WhatsApp, and Email, but each channel was still its own island.

I defined what "conversation" meant as a product object, wrote the vision, PRD, and functional requirements, prioritised Phase 1 vs. what to defer, worked directly with engineering on the data model and channel-switching architecture, stayed close to CS and O&I to validate the pain, and coordinated with Design on the unified agent workspace.

Engineering leadership owned the final technical architecture calls and infrastructure tradeoffs; pricing and GTM sat with senior product and sales leadership. My ownership was discovery, the PRD, prioritisation, and delivery of the omnichannel workstream end-to-end.

✦

The Problem

Agents were losing context every time a customer switched channels. Candidates got asked the same screening questions twice, and the same complaint kept surfacing in CS calls and O&I feedback.

They didn’t want to manage a mobile number. They wanted to manage a relationship with a person.

✕ Multi-channel

Present on every channel. Each one is its own island: separate threads, no shared context, agents repeat work.

✓ Omnichannel

Every channel feels like the same conversation. One thread, one history, context that survives a channel switch.

✦

Discovery

The channel is not the conversation

Customers don’t think "I’m having a WhatsApp conversation." They think "I’m talking to this company."

Agents were working around the product

Teams were copy-pasting summaries between threads and keeping parallel CRM notes just to hold onto context.

Foundation before features

Shipping AI and channel-switching first would’ve just inherited the same disconnected architecture underneath.

Source: 7–8 enterprise interviews · 3 months of CS/O&I notes · Recruitment, Healthcare, Education

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, so I made it a habit to sit in on their calls and pull patterns from the feedback backlog. I used them as a continuous loop, showing early prototypes to O&I before engineering picked anything up. The same “agent has to repeat the conversation” problem came up across staffing firms losing candidates mid-screening, healthcare teams re-verifying patient info, and education admissions teams managing four channels with no unified view.

The 7–8 direct customer interviews put a sharper point on it. The majority raised the same issue unprompted, without me asking about channels at all.

✦

Key Decisions

Redefine "conversation" as a first-class object

Every omnichannel feature, from routing to journeys to analytics, needed this foundation to exist first.

We redefined the Conversation as a core object with its own identity, lifecycle, and relationships, able to span multiple channels, hold context memory, and track participants, decoupled from the CRM’s object model. That was a real shift from how SMS-Magic had always worked: CRM data now fuels personalisation, but no longer defines the conversation’s structure. I worked closely with Engineering on this object model early, before writing a single feature spec, to avoid costly rework later. I also partnered with Design on the agent workspace built on top of it, since surfacing the right context without overwhelming agents took real UX thinking.

Context continuity before real-time switching

Seeing history in one place solved 80% of the pain; switching itself could wait.

Real-time channel switching is the exciting, demo-able feature, and there was pressure to ship it early. I pushed back. Phase 1 focused on unified conversation history and a single agent workspace instead, with real-time switching coming once that foundation was stable. Voice, journey automation, and AI sentiment routing were all deferred to Phase 2 on purpose: Phase 1 had to be about visibility before intelligence.

Own orchestration, integrate vertical intelligence

Kept the core product focused instead of rebuilding what integrations already do well.

Conversive owns routing, assignment, follow-ups, nudging, and usecase automation: the orchestration layer. Vertical-specific decisioning (candidate scoring, loan qualification, health assessments) lives in integrated systems and feeds into the conversation as data rather than being rebuilt natively.

Compete on orchestration, not channel count

Competitors treated channels as silos; ours runs AI at the conversation level.

Most platforms, including Intercom, Klaviyo, and Attentive, treat channels as campaign silos. Even the best shared inboxes, Gallabox and FrontApp, lack cross-channel AI context or journey-aware routing. That gap was the differentiator I structured the PRD around. Sales joined customer demos with me to see how enterprise prospects reacted to omnichannel positioning, which directly shaped which differentiators we led with.

✦

How It Works

Conversive architecture showing how a message flows from a CRM event through integration to the live agent environment

✦

What We Built

—

Conversation as a unified object. Every interaction belongs to one entity with its own ID, lifecycle, and context memory.

—

Unified agent workspace. One view of every channel, with no tab-switching and no duplicate records.

—

Context continuity across channels. The thread follows the customer; agents see history before typing a word.

—

Journey Orchestrator. A visual flow builder for multi-channel journeys triggered by real events.

—

AI-augmented routing & nudges. Sentiment shifts trigger automatic escalation or a nudge, in-context.

—

Cross-channel analytics. Unified dashboards at the conversation level, not per channel or campaign.

The Conversive inbox open on a laptop, unified across SMS, WhatsApp, and other channels

✦

Outcome

We onboarded 10 enterprise customers to a beta, then shipped and refined toward a sellable V1, with no big-bang launch. Today all 30 customers run on the omnichannel foundation we built, on a brand-new product with no legacy upsell to lean on.

What shipped

✓Unified conversation object

✓Agent workspace

✓Journey Orchestrator

✓AI sentiment routing

✓Cross-channel analytics

What I'd measure next: Context-preserved conversations % · Context-loss CSAT mentions · Cases per agent · Cross-channel conversion by vertical

✦

What I'd Do Differently

Underestimated routing

Intent-driven routing needed to be a Phase 1 problem, not something we’d bolt on later.

Deciding which agent, queue, or automation handles an incoming message turned out to be the most revisited decision in the project. You can’t route well without understanding intent, and intent isn’t always obvious from the channel or message alone. We got it working, but parts still feel fragile. I’d treat intent-driven routing as a first-class Phase 1 problem next time, not something to solve incrementally.

Should’ve pushed harder on the architecture upfront

Multiple rounds of design still missed SLA and assignment edge cases that forced a mid-build change.

We spent real time in solution design before starting, but routing configuration 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. The hardest cross-functional conversations were exactly these: telling engineering the model needed to change after work was underway. Getting it right mattered more than avoiding the disruption. I’d stress-test against SLA and assignment edge cases harder before locking anything in.

Voice was an unplanned curveball

An acquisition made a deliberately-deferred capability the next priority. Extensible architecture mattered more than I’d planned for.

Voice was explicitly out of Phase 1 scope. Then, shortly after Phase 1 shipped, the company acquired Voxgenie, a voice AI solution, and the decision was made to integrate it into the conversation object I’d just spec’d. Making it fit required real rethinking of the object to handle synchronous voice alongside asynchronous messaging. Even when you’ve scoped carefully, external factors can reshape the roadmap fast.

Next chapter: Voice AI →