Demo Client Management: Sales Demos At Scale

The Problem

Sales relied on a single shared demo client to show Lyric to prospects. Only one demo could run at a time — if two reps demoed concurrently, one's changes would bleed into the other's, interrupting the sales script.

Resetting data meant a white-glove backup restore from the persistence team, which could take days to schedule, so reps manually created employees and other data to cover each demo scenario instead. Standing up a new demo client for a different configuration was partially white-glove too — the client management team was involved, and it still required the persistence team to provision the database.

I came across this in an informal conversation with a sales team member at a company happy hour, not as an assigned project.

The Goal

• Let sales self-serve: create, reset, and run demo clients without involving the persistence or client management teams.
• Make it fast enough to use between meetings, not just for scheduled setup.

The Approach

• Investigated the problem and built the fix independently, using Lifion's own designers exclusively — the same no-code tools customers used.
• Built Demo Client Management: a self-service dashboard plus backend services for the sales team.
• Core mechanism: snapshot a demo client's database as a dataset in S3; create a new demo client from a snapshot; restore an existing client back to that snapshot's state.

Technical challenges & solutions

• Client setup — used the Client Lifecycle Management (CLM) team's existing API to create/delete client configurations and enable/disable features when standing up a new demo client from a dataset.
• Snapshotting — the orchestrator service (Node.js) read the client's details (name, ID, logo, etc.) and enabled-feature configuration, then created an S3 folder and manifest file for the dataset. For each data table defined in metadata for each enabled feature, it posted a message to SQS for one of several Worker service instances to pick up; each worker streamed that table's records to a JSON file in S3, along with copies of any referenced images or documents.
• Straightforward restore — demo clients lived in the same multi-tenant Postgres database as everything else, so most records only needed their client ID — part of a composite key with the record ID — rewritten on import.
• Harder case: users and referenced documents — these were indexed differently, so a client-ID rewrite alone wasn't enough. The orchestrator created the new users and uploaded the company logo before data import began, storing the new IDs (and client ID) in a Redis hashmap keyed by the original ID plus a run ID. During import, each worker fetched the table's metadata to identify which fields held reference data, then used the hashmap to swap each original ID for its new one. The same approach worked for documents per table, which were stored in S3 and referenced by ID in the database.

The Impact

• Clients could be set up or torn down by a sales rep in under 5 minutes, at the click of a button — no persistence or client management involvement.
• Reps could reset their own demo system between meetings, including while traveling from one prospect to the next.
• Multiple demo clients let the team tailor demos to a prospect — e.g., a construction-industry configuration vs. retail, or a flat org structure vs. hierarchical.
• Ad-hoc prospect questions could be demonstrated live instead of just described.
• Unblocked concurrent, non-interfering demos and increased how often sales could run prospect-facing demos.