How we built the Carom demo

A few weeks ago we argued that there are only bad reasons not to have a good demo, so it’s only right that we introduce ours and describe how we built it. The short version: we leaned heavily on LLMs to create a substantial amount of realistic data. But to do that, we needed to first invent a company, called Bankshot: five employees, a cast of customers and investors and job candidates, with twenty-two detailed storylines that paint a realistic portrait of how teams collaborate. Only then did we create a single email, file, or task.

Carom is built around a team’s real working life: email threads, meetings, contacts, tasks, comments, files, and a group of team members with their own personalities, roles, and styles who work with them. We think prospective users deserve realistic demos, and for a collaborative product like ours, an empty account would do nothing to capture the actual experience of working with it.

Why “make me a bunch of emails” doesn’t work

The naive approach—which was, admittedly, our first one—is to simply ask an LLM to generate data. Quantity at speed is where LLMs excel: for a human to write 500 emails by hand would be a week’s work, but for an LLM it takes minutes. But you quickly find that to get the kind of variety you want, you need to be more thoughtful than simply asking for emails. Some are short messages from the CEO, some angry tirades from customers, others detailed requirements from prospects.

And it’s not enough for individual emails to be good, or even for an inbox’s worth to seem realistic. What you need is a coherent story across emails, contacts, organizations, files, and tasks—and of course over time, so that there’s a cadence that feels natural.

So instead of asking for raw materials without a vision, we thought like playwrights. LLMs wrote the individual content, but we needed to define the broader context first:

First, our cast of characters had personalities, styles, and backstories

That’s what makes it feel realistic to dip into each one’s mailbox. The patterns of who they email, what they say, how quickly they respond—all are defined by a set of character traits and backstories. Here’s Alex’s, with the actual YAML code we used to create emails in his voice:

name: Alex Chen
email: alex@bankshotsoftware.com
role: CEO & Co-Founder
mailbox_type: personal

bio: >
  Founded Bankshot 3 years ago after a decade in enterprise SaaS. Deeply
  involved in strategic sales, investor relations, and partnerships. Delegates
  day-to-day customer relationships but stays close to key accounts. Often the
  closer on enterprise deals.

communication_style:
  tone: Direct, confident, warm but concise
  email_length: Short — rarely more than 3-4 sentences
  habits:
    - Responds quickly, often from mobile (short replies, occasional typos)
    - Forwards threads to the team with one-line context ("FYI — let's discuss")
    - Signs off with just "Alex" or "- A"
    - Uses first names immediately, even with new contacts

typical_interactions:
  external:
    - Executive-level introductions and relationship building
    - Late-stage sales conversations (pricing, contracts, timelines)
    - Investor and advisor updates (quarterly emails, ad-hoc check-ins)
    - Strategic partnership discussions
    - Conference follow-ups and warm intros
  internal:
    - Forwarding inbound leads to sales@ or team members
    - Weighing in on escalations (CC'd, not primary)
    - Quick Slack-style "thoughts?" emails to Morgan or Sam
    - Finance discussions with Taylor on deal terms

cc_patterns:
  - Gets CC'd on large deal threads from sales@
  - CC's Jamie when handing off post-sale relationships
  - CC's Taylor on threads involving pricing or contract terms

email_signature: |
  Alex Chen
  CEO, Bankshot
  alex@bankshotsoftware.com

When you try our demo, you can see Carom just as Alex would, including content that is private to him. You can dip into the life of any of the team members, in fact, so you can see how they all use Carom to manage their work and collaborate. If you do, you’ll get the distinct sense that they’re different people. Alex is terse, as you might expect from a CEO; Jamie, who leads customer success, is as warm and thorough as you would expect.

We also have shared mailboxes—sales@ and support@—that don’t have personalities per se, but do have the sort of inflow that will be familiar to companies that deal with prospects and customers who email a shared inbox before a specific contact.

Next, we created realistic and varied narrative arcs

We had our internal cast; next, we needed to decide the plot. We created twenty-two narrative arcs, each several hundred lines of background outlining outside companies, the secondary cast members who work for them, and the specific interactions they’ve had with our fictional Bankshot team. Some are happy: a long-term customer expressing gratitude, a win-back after a customer churned, and a new client coming over from a competitor. Others are—as in real life—stories of challenges: an enterprise deal stuck in procurement, a lost account, a stalled deal with a number of stakeholders who can’t get aligned.

Here’s a snippet of the arc definition for just one of our clients:

name: Enterprise Deal in Progress
status: active — mid-funnel, high momentum

contacts:
  - name: Rachel Dominguez
    title: VP of Operations
    role_in_arc: Executive sponsor, primary decision-maker
    notes: Warm, direct, busy. Delegates details but stays in the loop.

  - name: Priya Nair
    title: IT Security Lead
    role_in_arc: Security and compliance reviewer
    notes: Enters late in the process with a security questionnaire. Thorough.

narrative: >
  Arcwell found Bankshot through a conference talk Alex gave. Kevin reached
  out via sales@ with detailed questions. After an initial demo, Rachel got
  involved and had a direct call with Alex. The deal has progressed through
  technical evaluation (Kevin + Sam on a call), security review (Priya sent
  a questionnaire), and is now in commercial negotiation (Taylor involved on
  pricing/terms). Jamie is CC'd on recent threads as onboarding planning
  begins.

threads:
  - subject: "Arcwell Health — Security questionnaire"
    mailboxes: [alex]
    participants: [priya.nair, kevin.yoo]
    message_count: 4
    age_days: 18
    summary: Priya sends security questionnaire, Alex coordinates responses.

There’s still no actual content a demo user will see; the emails and files don’t exist yet, but the general contours of the relationship do. And arcs reference each other’s contacts by slug, so the happy customer from arc 02 can make the referral in arc 17—a connection that wouldn’t happen without the centralized context.

Also, importantly: because these narratives are self-contained, we can create as many as we need. If someone wants to watch our demo users deal with a situation like one they’ve faced, we can add it. If we wanted a full demo account for an architecture client or a non-profit or anything else, we could create a whole new set of narratives.

Finally, we created the content

Now we’re ready to create the hundreds of emails that make up our demo account today. Each arc goes to an LLM with four inputs: a system prompt, the relevant persona profiles, the arc overview, and the output schema. The system prompt is mostly rules about form and tone, which ultimately contribute a great deal to the realism we hope to achieve.

The output is what you’d hope for. Here’s Alex—short, direct, mobile-adjacent—handling scheduling with Rachel’s assistant, exactly as the profile prescribes:

The same model, handed Jamie’s profile instead, sounds like a different person entirely. Here’s the 30-day check-in from the happy-customer arc—warm, bulleted, a clear ask with the pressure taken off:

Across the twenty-two arcs, there are a total of 441 emails in 123 threads, plus 55 calendar events, 63 tasks, 133 internal comments, and 55 file attachments—all adhering to the rules of our make-believe company.

When you try the demo, you might notice a few other niceties—or maybe you won’t notice because they’ll just feel right:

• The reference files—the board materials, RFP, and other documents that our characters are talking about—actually exist, so you can follow from thread to file without breaking the illusion.
• Dates are all relative, so whenever you create a demo account, you’ll see information from the recent past and events in the near future.
• Times of day are respected, so most emails cluster between 8 and 6, with some quick replies (perhaps especially from our busy founder) late at night.

Is this overkill? Quite possibly. We didn’t need to create the blank security questionnaire and the finished one, or the MSA that goes out in draft format and comes back redlined. But if you want to do some realistic world-building, you have to sweat these details.

A bespoke environment for every demo user

Beyond realism, we had another critical requirement. We needed to let people do whatever they wanted in their demo environment to understand what it would be like to use Carom, which means you can delete contacts, add comments, and otherwise change what you want. We also needed the next demo user not to suffer if you chose to mess up our carefully crafted creation.

That means every user gets their own custom demo—the same initial content, centered around the day they created it, so they have the freedom to make their own mess without dealing with anyone else’s. We sweep the demos clean once a week, but users can always create new ones for themselves or their colleagues.

I invite you to try it out; there’s nothing quite like experiencing the real thing. And if you have questions about what you see or how we built it, as always, please just let us know at partner@carom.io.