Shipping VoiceConnect to GA.

VoiceConnect is Sprinklr's integrated telephony layer for CCaaS — the bridge between the Service platform and a customer's telephony infrastructure. When it breaks, contact centers feel it instantly: call failures, SLA breaches, frustrated customers.

This wasn't a feature update. It was a New Product Introduction heading toward GA with enterprise customers like Samsung adopting it. I owned the UX research component: confirm the product was ready, identify what wasn't, and give product + infra a prioritized, decision-ready picture of both.

VoiceConnect serves a technically complex ecosystem — infra engineers, customer IT, CCMs, and support engineers — each needing something different from the same product.

Each method was designed to build on the last — structured evaluation → live behavioral observation → quantitative validation at scale. No parallel aggregation.

USE scored above the 3.5 "Good" threshold on most heuristics — strong for a new product. But Flexibility & Efficiency of Use scored a 2: manual regex via Postman, no SBC load-balancing UI, workspace-scoping confusion.

The infra roundtable gave those structural flags human weight — credential-exposure concerns, missing audit trails, real-time feedback gaps for IP whitelisting.

The move that mattered: in Jira, I attached the relevant customer account to each ticket. When Samsung's name sits next to a credential-masking gap, it stops being a UX concern and becomes a business risk. That's what gets prioritized.

Findings organized into three tiers: ship-before-GA (or measurable security/operational risk), commit-next-cycle with named ownership, and acceptable-to-defer with a clear plan.

Every finding became a Jira ticket with source attribution, severity, customer linkage, and a committed release target. The product team got a ready-to-execute backlog, not a list of observations.

VoiceConnect sits at the intersection of four audiences who barely speak the same language — infra engineers, customer IT, contact center managers, and Sprinklr's own support engineers. A single method would have either flattened the differences or missed the structural issues entirely.

So I sequenced three: USE heuristic evaluation first, to find the structural product issues I could spot without users; an infra-engineer roundtable second, to give the structural flags real human weight from people who actually deploy SIP trunks for a living; and a quantitative survey third, to validate whether the patterns generalized beyond the seven people in the room.

Each method's output was an input to the next. The roundtable's discussion guide came directly from the heuristic flags. The survey's question set came directly from the roundtable's themes. Nothing ran in parallel because parallel methods just produce parallel findings — they don't compound.

The change that did the most work wasn't methodological — it was operational. In Jira, every ticket I filed had the affected customer account attached as a custom field.

A credential-masking gap is a UX concern. The same gap with Samsung's name attached is an enterprise business risk. PMs prioritize the second one. Engineering leadership escalates the second one. The same finding, framed against the actual revenue at stake, moved tickets from "someday" to "this release" without me having to advocate for any of them.

I do not throw research over the wall. From the first heuristic flag, I was in the VoiceConnect pod's standup once a week. Every Jira ticket I filed had acceptance criteria written by me and a proposed release target — so the conversation in triage was "do we agree with the target," not "what does this even mean."

When the team pushed back on a finding, I treated that as signal. Twice it surfaced architectural context I hadn't seen, and I rewrote the recommendation. Once it surfaced a real disagreement about risk tolerance, and I escalated cleanly with the customer-account data attached.