Letting Sales Build Client Demos Themselves

Every demo was an engineering request

Sales engineering needed a branded demo environment for every serious prospect call, and each one was an engineering request. Someone cloned a setup, themed it by hand, loaded plausible data, and handed it over.

The requests queued behind feature work, so demos arrived late or already stale, and the people running the calls could not change what they showed.

Real behavior, sample data, nobody on call

A demo had to look and behave like the real product while containing nothing real, so every environment needed its own provisioned demo users and sample data. The tooling also had to route each demo to the correct environment, and it had to be operable by sales and support without an engineer on call.

A creation and handoff workflow, end to end

I built the demo tooling as a product of its own, where a demo is created from a form, provisioned with its own users and data, and handed off to whoever runs the call.

A shared data grid gave every demo the same plausible records, and environment aware routing sent each one to the right API without per-demo configuration. Consolidating the surrounding admin shell was a side effect of this work, done so the tooling had one coherent place to live.

Handoff as the unit of work

The workflow was designed around handoff rather than creation, because the person who builds a demo is rarely the person who presents it. Every demo carries its configuration and data with it, so it survives the exchange.

Provisioning happens inside creation instead of as a separate step, so a demo is usable the moment it exists and nobody assembles credentials by hand.

Demos created without waiting on engineering

Sales engineering and customer support create, provision, and hand off their own branded demos, and engineering left the request path. A new demo takes minutes of form filling, with provisioning included.