Reps get good by practising on people. That doesn't scale.
Sellers learn objection-handling and discovery by doing — which usually means pulling a manager or peer in to play the buyer. It's inconsistent, expensive, and never available at 11pm before the call that matters.
Mindtickle's edge was a roleplay bot with genuinely low latency and human tonality — one you can talk over and interrupt. The business wanted two things from it: let prospects try it without an account, and give existing customers' reps the same practice inside the product. One engine had to do both.
Two surfaces. One codebase.
The same React app ships as a public lead-gen trial and as a module embedded inside the Mindtickle platform — a deliberate architecture decision, not two forks.
roleplay.mindtickle.com
Pick an industry → pick a buyer persona → run a real call in seconds → get scored. No login, served straight from a CDN, live in seconds. It doubles as a lead-capture funnel.
Embedded micro-frontend
The identical app loads inside the Mindtickle app as a Module-Federation remote — so customers' reps practise against the same bots without ever leaving the platform.
A real-time voice pipeline, wired to be model-agnostic.
Voice is orchestrated by Vapi as a real-time speech-to-text → LLM → text-to-speech loop over WebRTC. Each persona maps to a preconfigured assistant carrying its scenario prompt, traits, and time limit.
Provider-agnostic model layer
The buyer's brain is configured behind the assistant, not hard-wired — the same persona runs on GPT-4o (OpenAI) or Claude 3.5 Sonnet (Anthropic). Swapping models is a config change, not a rewrite. In a space moving this fast, that optionality is the point.
One state machine, three entry modes
The flow — Industry → User Info → Persona → RolePlay → Processing → Insights — is a single engine driven by three entry modes: new user, legacy query-param, and mirror / integration. Backward-compatible by design, so older integrations kept working as the product grew.
Module Federation — standalone and embedded
Webpack 5 Module Federation lets the identical app run as its own site and as a remote inside the platform shell. This is the decision that makes "two surfaces, one codebase" true rather than aspirational.
The payoff: an AI-scored breakdown the second you hang up.
The moment the call ends, the app computes a full transcript, an AI success-evaluation, and derived metrics — call score, pace, talk-percentage, filler words — rendered client-side, with a live waveform for both the bot and the rep during the call.
The trial isn't a demo — it's a lead-gen machine.
The front end is wired into the go-to-market stack: a campaign page hands off query params that build industry-specific personas; a per-IP limiter nudges heavy users toward a demo; and reaching Insights pushes the roleplay data through Marketo → Salesforce, then routes "Request a demo" to a live rep by geography.
Personas + rate limiting
Query params (industry, name, email) populate the persona grid; a per-IP limiter routes heavy users toward booking a demo instead of unbounded free usage.
Marketo → SFDC → geo-routed demo
Reaching Insights fires the lead into Salesforce; a qualified-routing integration books demos with an available rep in the prospect's region.
Fast by design — and used for real.
Because the trial is a top-of-funnel asset, performance was a feature. Measured on Google's throttled 4G profile:
Performance figures from WebPageTest / Lighthouse. Usage figures are directional, drawn from internal product reporting and shown without confidential targets.