48 hours to a Business Central demo that closes — from someone who runs them for a living, not a marketing team who's watched one.
This is a practitioner's guide, not a product pitch. Worksnip appears on exactly one page — Chapter 5 — and nowhere else in this document. No fabricated statistics, no timed benchmarks: where a number would normally go, there's a practitioner heuristic instead.
The Business Central functional consultant, pre-sales engineer, or partner AE who runs demos for a living — weekly, sometimes daily — and has felt the exact moment a demo either locks in a deal or quietly loses one.
None of what's in here is theoretical. It's the version of demo-prep and demo-recovery I actually use, written down instead of re-learned the hard way every few months. There are no timed benchmarks and no invented statistics in this playbook — where a number would normally go, there's a heuristic instead, because I'd rather give you something true than something that sounds impressive.
Print it, export it to PDF, or read it on-screen — built to do all three cleanly.
A good demo is decided mostly by what you did in the two days before it, not by what you say in the room. Here's the timeline I actually follow — not a generic "test your equipment" checklist, the specific things that go wrong in a Business Central sandbox.
This chapter runs on general BC demo-prep craft. If you've got a specific sandbox-refresh or shared-tenant horror story from a real engagement, it will land harder with your audience than anything generic here — swap it in.
Almost every "the product looks buggy" moment I've watched in a BC demo traces back to something in this 24-hour window that got skipped, not to the product. The script is the easy part. This window is the part that actually decides the demo.
Before you go live, ask yourself one question honestly: "If this demo goes wrong today, where does it happen?" You almost always already know the answer — a flaky integration, a permission you never quite finished setting up, a workflow you've only tested twice. Chapter 4 is built directly around the honest answers consultants give to that question.
A Business Central demo rarely has one audience in the room, even when it looks like it does. Miss this and you deliver a technically perfect demo that nobody in the room can champion internally afterward.
Don't run one script at everyone. A rough rule that works: about ten minutes per persona, in the order the room's real decision-maker wants, and name the shift explicitly ("Now let me show the ops side of this...") so each person knows their moment is coming instead of tuning out during someone else's ten minutes.
These are the scenarios I reach for most — not because they're impressive to watch, but because each one answers a specific, common objection before it's raised out loud.
This list runs on general BC demo craft across verticals. If you've got a scenario from a real recent engagement that actually closed a deal, it will out-perform anything generic here — swap it in, keep the same "wins / click path / talk track / objection" shape.
Every BC consultant who's run enough demos has had one break live. The difference between a recoverable moment and a lost deal is almost never the failure itself — it's the ten seconds right after it.
Recovery: acknowledge it plainly — "that's a role-center permission I have set too tight for this demo user" — then keep moving to a screen that works. A brief, calm acknowledgment reads as competence, not incompetence.
Recovery: this is usually a fast, visible fix. Narrate it as the system doing exactly the validation you'd want on a real transaction — not as a failure.
Recovery: pivot straight into narrating the delegation feature — "this is actually the exact scenario a substitute approver solves, let me show you how we'd configure that" — turning the break into the next talking point instead of dead air.
Recovery: acknowledge the network, not the product — "that's today's sandbox connection, not the app" — and have a backup recording ready to switch to without losing the room.
Recovery: this is exactly why you warm report layouts in the T-2h block (Chapter 1). If it still fails live, pivot to a different report you know works and revisit the failed one afterward — never debug a layout live in front of the prospect.
Recovery: catch it fast, name it lightly — "wrong company, hang on" — and switch. A quick self-correction is forgettable; a slow, confused one isn't.
Recovery: disable the conflicting extension live if it takes under ten seconds; otherwise pivot away from that feature and follow up afterward (Chapter 5) instead of troubleshooting live.
Recovery: narrate through the expected behavior verbally while it resolves, or reorder your script so that scenario lands last, when a slow retry won't stall the middle of the demo.
The prospect is watching how you handle the unexpected at least as much as they're watching the software. A calm, honest recovery is itself part of what you're selling — a consultant who won't panic during their actual go-live either.
The gap between a great demo and a signed deal is usually the 48 hours right after the call — when the champion inside the prospect's org has to explain to two or three other people what they just saw, from memory, without you in the room.
The follow-up that actually moves a deal isn't a generic one-pager or a re-sent deck. It's a recap of the specific workflow you actually ran, sent the same afternoon, that the champion can forward as-is.
I built Worksnip because I was doing that by hand — recording my own screen, then writing up the recap at 9pm before the prospect's team logged off. It's a Chrome side-panel: it watches the demo as you run it, and turns the capture into a narrated walkthrough or a written brief, citing the actual Microsoft doc on any step that has a definitive answer. It doesn't replace your talk track — it's the leave-behind.
Honest limits: it's not a deck generator, it doesn't invent a business case, and it only captures what happens in the browser tab you're recording. What it does is turn the demo you already ran into something the champion can send around without retyping it.
"Trainings, demos, onboarding, the how-to that comes up in chat — all worksnips now. We stopped editing them, and the team stopped re-asking the same questions."
— Sara M., Functional Consultant · Munich
No free tier, no trial — a consultant's own call, month to month. Dynamics 365 Sales narration ships on the Business plan and up.
See the full pricing and try it at worksnip.com.
Iraj is a Business Central functional consultant who runs demos, UAT sessions, and go-lives for a living — and the person building Worksnip, a Chrome side-panel that turns that same work into narrated, doc-citing guides.
Nothing in this playbook is secret knowledge — it's the ordinary discipline of doing demo-prep properly, written down instead of relearned every few months. If one chapter saved you from one bad demo, it did its job.