Work Case studies About Contact Resume ↓

Case study · UpViral

Product Modernization & AI Growth Platform

Evolving a mature referral marketing SaaS from manual campaign building toward proactive growth automation.

Technical Product Manager · Feb 2025 – Present

UpViral has a powerful referral marketing engine and a setup journey that had not kept pace. I led an AI-first modernization across the customer lifecycle: reducing activation friction, opening a new offline acquisition channel, and designing AI workflows for support and revenue. Two of these shipped. One is a scoped concept included to show how I think about AI products before they are built.

Where this fits

Customer lifecycle arc A six-stage lifecycle band from Onboarding through Revenue, with four modules mapped underneath: AI Onboarding Flow, QR Campaign Mode, and AI Support are shipped; AI Revenue Agent is a concept spanning Retention and Revenue. Onboarding Activation Acquisition Support Retention Revenue AI Onboarding Flow QR Campaign Mode AI Support AI Revenue Agent Shipped Concept
Each shipped module sits at a specific point in the customer lifecycle. The AI Revenue Agent spans retention and revenue and remains a scoped concept, not yet built.

QR Campaign Mode

Shipped · Feb 2025

Bringing referral marketing offline.

The signal. PostHog surfaced a pattern leadership had not named: D2C businesses with physical locations were starting trials and not converting. The product quietly assumed every campaign lived behind a digital link. Businesses operating in stores, at events, on invoices and packaging had no way to run UpViral where their customers actually were, so they trialled, found no fit, and left.

The decision. Rather than build a heavy offline suite, I scoped a focused mode: multiple QR codes per campaign, each representing a distinct physical source, each independently tracked. That single decision, many codes per campaign rather than one, is what turned UpViral into a tool that could attribute offline traffic instead of just generating it.

What it does. One campaign can carry many QR codes: the till, an invoice, an event flyer, product packaging, a poster. Each code reports its own scans, leads, signup rate, last-scan activity, and days active. Days active matters specifically because there are multiple codes per campaign. A flyer printed for a weekend event and a sticker on permanent packaging have very different lifespans, so normalizing performance by how long each code has been live is the only way to compare sources fairly. Without it, a long-running till code would always look like the winner purely because it had more time on the clock.

The pushback I navigated. Internal pressure pushed two ways: heavy per-code customization, and gating the feature behind a higher pricing tier. I argued against both. Over-customization would slow time-to-value for a feature whose whole point was low-friction setup. Gating a discovery-stage feature would suppress the adoption we needed to even prove the segment was real. We shipped it accessible and simple.

Outcome.

QR attribution flow Four physical sources, store till, invoice, event flyer, and packaging, each carrying their own QR code, converge into a single campaign. Per-source attribution reports scans, leads, signup rate, last scan, and days active for each source. Store till Invoice Event flyer Packaging Campaign (multiple QR codes) Per-source attribution Scans Leads Signup rate Last scan Days active Days active normalizes sources of different lifespans
Days active normalizes for sources that have been live for different lengths of time, a flyer posted yesterday shouldn't look worse than packaging that's been in circulation for months.

Takeaway: PostHog surfaced a segment leaving silently. A small, ungated, multi-code feature converted it, and per-code granularity made the channel measurable rather than just present.

AI Support

Shipped

Making human agents faster without ever replacing them.

The constraint that shaped everything. UpViral's support has always been a point of pride, and leadership was explicit: no full chatbots, nothing that risks degrading support quality or trapping a customer with a bot. That was not a hurdle to route around. It was the design brief. The goal was to make human agents materially faster on a high volume of repetitive questions without removing the human from a single interaction.

The model: AI-assisted, not AI-automated. I deliberately avoided building a chatbot. The AI drafts the response. For every assisted conversation, it reads the ticket and the support history, generates a proposed reply, and hands it to a human agent who reviews, edits if needed, and sends. The customer is always talking to a person. The AI removes the blank-page time and the lookup time. Premium and high-touch cases route straight to a human with no AI draft at all.

The build. I evaluated vendors before committing. Intercom Fin was capable but expensive at our volume. I scoped the alternative on OpenAI Assistants integrated with Freshdesk, which gave us control over knowledge ingestion and kept the human in the loop by design rather than by configuration. I deployed it first on the existing platform as a deliberate testing ground before migrating to the new one, so we could prove the quality bar held before scaling.

The scaling curve. We run roughly 750 support conversations a month. I started conservatively: about 200 a month were AI-assisted at launch. We watched quality, agents trusted the drafts, and we expanded coverage deliberately. We are now at 400 to 500 AI-assisted conversations a month, well over half of total volume, with no compromise to the support standard leadership was protecting.

Outcome.

AI-assisted support flow Knowledge base and support history feed an AI draft layer. Repetitive, answerable tickets route to a human agent who reviews, edits, and sends the draft. Premium or high-touch tickets skip the draft and route directly to a human agent. Both paths end with the customer, always a person. Freshdesk is the ticketing layer underneath the whole flow. Knowledge base + support history AI Draft Layer (proposes a reply) no draft Human agent: reviews, edits, sends Human agent: handles directly No auto-resolve branch Customer (always a person) Freshdesk, ticketing layer
Both branches end with a human in the loop, there's no path where a reply reaches a customer without a person approving it.

Takeaway: the constraint, support quality is sacred and no chatbots, became the design. An AI-drafts, human-sends model delivered the speed without touching the thing leadership cared about protecting, and earned the trust to scale.

AI Revenue Agent

Concept · Scoped MVP

Human-in-the-loop growth automation.

Concept and MVP scope. Not shipped. Included to show AI product thinking and scope discipline.

The idea. Customer, order, payment, and referral signals already exist across Stripe, Shopify, and UpViral's own referral API. An agent could read those signals, detect a specific revenue opportunity, draft a tailored action, and hold it for human approval before anything sends. The throughline from the support work is deliberate: AI proposes, a human decides.

Scope discipline. The interesting work was what I cut. I trimmed the MVP to two revenue-linked opportunity types, failed payment recovery and dormant customer reactivation, and pushed everything else out of v1. The point of the MVP was to prove one end-to-end loop worked, not to build a platform.

In scope (v1)

  • Stripe + Shopify test data
  • Customer profile + opportunity scoring
  • AI-generated recommendation + email copy
  • Approval queue (approve / dismiss / edit)
  • UpViral native email execution

Cut from v1

  • Auto-send
  • External ESP integrations
  • Full dashboard
  • Multi-brand customization
  • Incentive logic and ML training

How the agent reasons. For each customer it builds a cross-signal profile (last purchase, order value, refund history, payment status, referral and engagement history), then scores the opportunity on recency, order value, and signal strength to decide whether an opportunity exists and which type it is. If it clears the bar, it generates the recommendation and the email copy, each carrying an explicit reason and a signal summary, and drops it into the approval queue.

The non-negotiable. Nothing auto-sends. Every item in the queue shows the customer, the opportunity type, why it was flagged, the confidence, the estimated value, and editable AI copy. A human approves, edits, or dismisses. Explainability and the approval gate were requirements, not nice-to-haves, the same principle that governs the shipped support work.

AI Revenue Agent loop, concept Concept, scoped MVP. Pipeline: scan data from Stripe, Shopify, and API sources, build a cross-signal profile, detect and score by recency, value, and signal, generate an action with reason and copy attached, then drop into an approval queue where a human approves, edits, or dismisses the action, nothing auto-sends. Only after approval does the agent execute via native email and log the outcome. CONCEPT · SCOPED MVP Scan data Stripe · Shopify · API Build profile cross-signal Detect + score recency · value · signal Generate action + reason + copy Approval queue human approves / edits / dismisses Nothing auto-sends Execute native email Log outcome feeds back into profile
The constraint that matters most here isn't the model, it's the approval queue: this only ships if a human can trust what's in it.

Why it is here: it shows AI PM range, MVP prioritization, data-model thinking, and the same human-in-the-loop instinct that runs through everything I shipped, without claiming outcomes it never earned.

Decisions worth surfacing

← Back to vibhormadan.com