Preparing for the demo: which trigger do you bring?
The trigger: You’ve read the page, understood the system — and you’re thinking: nice, but does it work with my mess? That’s exactly what the demo is for. It only gets useful if you don’t show up empty-handed, but with a real, upcoming trigger. Then we don’t talk about an example of ours — we build the first artifact live, from what you already have.
What makes a good demo example?
- A real, upcoming trigger — not a hypothetical one. An audit (DORA, NIS2, a customer), an onboarding, an automation you’ve been pushing ahead of you for a while, a re-org. Something with a date or pressure behind it.
- A few existing sources — don’t clean anything up, don’t pre-produce anything. A few tickets, a wiki entry, a system export, an old doc. Raw is good. ProcessForge works with what’s already there.
- A clear question — what should come out at the end? A BPMN diagram, an audit-ready control mapping, a checklist, a podcast. The more concrete the artifact, the sharper the demo.
Why this makes the difference
A demo with sample material shows that something could work. A demo with your trigger shows that it works for you — on your real sources, with your edge cases, in your language. The jump from “interesting” to “I’m taking this with me” happens in exactly that moment.
Bring the trigger, not the tidied-up version of it.
And the best part: what comes out of the demo isn’t a throwaway mockup. It’s the first real artifact — the start of what the system pulls for you afterwards.
The preparation in one sentence
Pick the next trigger with pressure behind it, grab the sources already lying around, phrase a clear question — and bring exactly that.
To try it: Bring your trigger into the demo call — we’ll build the first artifact from it live.