Designing Plivo’s Shared Platform and Voice AI Workflows
At a glance
- The problem
- Legacy and newer products had separate interfaces and different design philosophies. As Plivo expanded into voice AI, we needed one unified product that could serve different personas, with a shared foundation and workflows suited to each role.
- The decision
- Bring the products together around a shared channel, logic and agent model, with role-specific workflows for the different personas using the platform.
- My role
- Associate Director, Design → Director, Design & Brand Strategy Plivo, 2023 to 2025
- Worked with
- CEO, product managers, engineering leads and designers across the product teams.
My contribution
- Set the design direction across four communication products, including a shared channel, logic and agent model.
- Recommended the messaging-product sunset, co-sponsored the sales-platform sunset and defined a six-month customer transition framework.
- Aligned product and engineering on delivery, established cross-team reviews and directed the move from visual workflows to prompt-based agent creation.
Project outcomes
- Vibe Agent reduced workflow building and testing from roughly one week to under one hour, including work by forward-deployed engineers preparing enterprise trials.
- Shared interaction patterns gave product teams a common foundation. Simulation testing let customers examine agent behaviour before deployment.
The Challenge: Disconnected Product Experiences
Starting in 2020, Plivo began building products for non-developer teams on top of its existing API infrastructure: a Sales Management Platform, a messaging and marketing platform, and a contact center for inbound support. These sat alongside the traditional voice and messaging APIs. Legacy and newer products reflected different design philosophies, with separate teams defining their own interfaces, navigation and interaction patterns. Customers buying multiple products encountered disconnected experiences from one company.
As Plivo moved toward voice AI, we needed one unified product that could serve different personas. That meant a shared foundation connecting voice, messaging and agent management, with workflows suited to each role. We also needed to decide which capabilities to retain and where to keep investing.
Sellular Sales Management Platform 
Contacto Contact Center 
Engage Messaging & Marketing 
API Communications Infrastructure Leading the consolidation
From 2023 to 2025, I led design strategy across four communication products and partnered with the CEO on AI product direction. The scope included the shared interaction model, product investment recommendations and the customer transition from legacy products. I recommended retiring the messaging product and co-sponsored the sales-platform sunset with executive leadership.
Across the product pod, I managed execution, timelines and solution development with product and engineering leads. Cross-team reviews gave designers a place to resolve competing patterns before they shipped. I brought evidence from configuration problems and conversation failures into architecture decisions owned by engineering.
The Strategic Decisions
What to keep, what to sunset
The messaging and marketing product had entered a market where competitors already covered most use cases at an effective cost. Without evidence of product-market fit, I recommended ending investment, and leadership agreed to focus on the inbound support opportunity where customers had a clearer need.
The Sales Management Platform was a much harder conversation. It had evolved from a simple dialer into a full-scale management tool, and it was generating revenue. However, the market was shifting toward AI agents, not outbound automation. As part of the executive leadership team, I co-sponsored the difficult decision to sunset it. We did not want to be a brand that contributed to outbound spam. To execute this safely, I defined a six-month transition framework: in-product notifications with a clear timeline, direct connections to account managers, and a maintenance-only policy with no new features during the wind-down. The framework prioritised continuity for enterprise customers during the transition.
The contact center’s inbound support work informed the voice AI platform. Customer support became our focus because enterprise customers were actively seeking voice AI for that use case, while the traditional API product carried forward as the infrastructure layer.
Instead of features locked inside separate products, channels, workflows, and agents became reusable building blocks. A voice channel could use the same logic engine as a messaging channel. An AI agent could be swapped in where a human agent previously sat. The pattern held across every use case we tested it against.
The shared model covered telephony infrastructure, API workflows and AI agents. Bringing the AI and API experiences together continued through the migration, with the design manager leading day-to-day design as my focus broadened to strategy.
The shared building block: Channel + Logic + Agent 
Contacto Voice Routing 
Engage Marketing Journeys The Workflow Builder Evolution
The interaction model for building voice agents went through three distinct phases, moving from manual workflow construction toward prompt-based configuration.
The first phase used a drag-and-drop canvas that worked for simple call routing, such as business hours, FAQ handling and forwarding rules, but became difficult to use as workflows grew more complex. Because users struggled to map abstract logic onto a visual canvas, setup still depended on technical support. Customers needed engineering support to build, refine and deploy complex agents.
Phase two introduced prompt-driven creation alongside the visual canvas. Users could describe what they wanted, and the system generated a workflow structure. Manual intervention was still required for editing, reordering, and deleting nodes. During this hybrid phase, we saw agents underperforming because customers would forget to plug in required actions (for example, a data-fetching step). The agent would then hallucinate because it could not access the data it needed. We had to go back and debug these configurations repeatedly.
Phase two, the hybrid builder. The AI generates the workflow structure from a prompt, and the customer still wires up and edits the nodes by hand. This is the stage where missing steps caused agents to hallucinate. Prompt-generated workflow with manual node editing and configuration The third phase introduced prompt-based agent configuration through a single-node architecture. The move from multi-node to single-node was driven by a clear product problem: context was not transferring cleanly between LLM nodes, causing conversation loops, broken flows, and increased latency. The change required engineering work on how context passed through the system.
Research showed that conversation quality degraded when context passed between nodes, so I brought that evidence into architecture discussions with engineering to shape the approach to context handling while they owned the implementation. The resulting builder generated an agent from a prompt, reducing the steps customers had to wire together manually. We also introduced integrated simulation testing so users can pressure-test AI logic safely before deployment.
Vibe Agent was in place before September 2025 and refined with further features afterward. Faster setup alone was not enough: customers also needed to test whether an agent could handle the conversations it would face. Testing and simulation became part of preparing an agent for use.
Phase three, the fully prompt-based agent builder. A customer describes the agent, the system generates it as a single node, and simulation testing runs before anything goes live.
Platform Decisions
Unifying the design language across teams
With two designers per product team, each product was developing its own patterns despite the existing design system. I directed the team to consolidate on a shared library built on shadcn/ui with Inter as the universal typeface. This was a deliberate constraint for a lean team: a component library that mapped cleanly to development meant the team could ship faster without sacrificing consistency. Overlapping patterns were identified in weekly cross-team reviews and reconciled before they shipped.
Permissions and role-based access
When the platform served human agents, I defined a seat-based permissions framework to solve two problems: directing incoming calls to the right person, and ensuring operators only saw what was relevant to their role.
The framework established three roles: admin (full platform access), supervisor (read and write access to workflows, no delete), and specialist (limited to customer interactions, quality monitoring, and read-only data access). This separation was critical for larger teams where not everyone should be able to modify call routing or access billing.
As the platform design evolved toward AI agents, admin and supervisor roles carried forward. We also mapped a dedicated billing and finance role for accounts with several stakeholders.
CDP (contact data platform)
I argued against a native contact data platform because live syncing would add infrastructure costs. The team built it to meet an immediate product need. As integrations became more capable, I advocated reassessing that investment rather than maintaining overlapping capabilities.
Making adoption a product decision
Enterprise customers needed to understand how an agent would behave before assigning it customer-facing work. I established the adoption framework around one insight: enterprises will not hand over control unless they can verify the AI’s behavior before it touches a real customer.
The framework began with simulation testing: before an AI agent handles a single real call, customers can pressure-test its logic against real conversation scenarios in a safe environment. This gives teams a way to examine the agent’s behaviour. Gradual rollout controls then let customers route a percentage of traffic to the AI agent while humans handle the rest, increasing the ratio as confidence grows. Performance data showed where the agent succeeded and where it fell back to a human, giving teams evidence to decide whether to expand.
The same principle shaped the six-month sunset windows for legacy products and the communication during those transitions, helping organisations assess and manage change while maintaining continuity for their customers.
Test Scenarios Caller Objectives 
Simulation Results Multi-Run Comparison 
Eval Metrics Quality Scoring 
Goal Results Conversation Analysis What changed
With Vibe Agent, building and testing an agentic workflow went from roughly one week to under one hour. We observed this across customers, including white-glove delivery by forward-deployed engineers preparing agents for enterprise trials. Customers could build more themselves, and engineers spent less time preparing workflows on their behalf.
- A shared product foundation: Channel, logic and agent became reusable building blocks across the communication products.
- A way to evaluate before deploying: Simulation testing let teams examine conversation behaviour before routing live customer calls to an agent.
- A managed transition: The shared model guided AI and API consolidation, while the six-month sunset framework gave legacy customers a defined path through the change.
How the team carried the work forward
Designers worked within product teams, with shared libraries and weekly reviews connecting their decisions across the platform. I used those reviews to resolve conflicting patterns and coach designers on the customer and business reasons behind a choice. That gave teams a common direction without requiring every detail to come through me.
As the design manager took on day-to-day platform leadership, my focus moved further into product strategy. Since becoming Director in September 2025, I have continued to bring market insights into feature priorities and critique final solutions through launch. The AI and API migration continued under that division of responsibility.
Reflection: Deciding What Should Exist
The hardest decisions concerned existing products and the teams behind them. A shared interface would not resolve overlapping capabilities. I had to work with product and engineering on what to retain, what to consolidate and how customers would move between them.
I would have tested demand for the messaging product earlier. The sales-platform sunset and the contact data platform required different decisions: one about ending investment, the other about the cost of maintaining a native capability. Those tradeoffs are the part of this work I would examine sooner next time.