How to write a government ERP demo script from your own processes, run it on your own data and score every vendor the same way.
Vendor demonstrations are the part of an ERP selection that most people on the evaluation team actually remember, and in my experience they are also the part where an agency has the most control and uses the least of it, because the schedule gets set, the rooms get booked and the vendors are left to decide what they will show.
I have sat through a lot of these sessions on both sides of the table, and the ones that produced a clear, defensible decision all had something in common, which is that the agency showed up with a plan that came from its own work rather than from a vendor’s sales deck. The good news is that none of what follows requires a bigger budget or a longer timeline. It requires deciding, before the first vendor walks in, what you need to see and how you will judge it.
Start with the script
Write the demo script yourself. If the vendor writes it, you’re grading a performance.
A vendor led demo is built to move smoothly from one strong feature to the next, and that is a perfectly reasonable thing for a sales team to want, but it means you spend three hours watching the paths the product handles best while the paths your staff walk every day never come up. When you write the script, you decide which paths get walked, and every vendor has to walk the same ones in front of the same people.
My view is that a good script reads less like a list of requirements and more like a set of stories about how your agency actually works. Instead of asking a vendor to “demonstrate purchasing,” describe a requisition that starts in a department, needs two approvals because it crosses a dollar threshold, gets split across a grant fund and the general fund, and then has to be partially received because only half the order arrived. That one scenario will tell your team more about a system than an hour of slides, because it forces the vendor to show how the pieces connect.
Build scenarios from your own pain points
The best source material for a demo script is the list of things that frustrate your staff today, and I usually find that the people closest to the work can name them in a single meeting if you ask the right way. Ask your payroll team where they rely on a spreadsheet the system cannot replace, ask your accounts payable clerks which month end steps they dread, and ask your budget office which reports they rebuild by hand every year because nothing produces them cleanly.
Those answers become your scenarios, and they are worth more than any generic checklist because they are specific to the way your agency is organized, the union agreements you live under, the grants you manage and the reporting your council or board expects. A vendor that handles your hardest cases well will almost certainly handle the easy ones, but the reverse is not true, and you only find that out if you put the hard cases on the table.
I also like to keep the number of scenarios honest. It is tempting to pack every concern into the script, but a demo that tries to cover everything ends up rushing through all of it, so I would rather see a smaller set of scenarios done thoroughly, with time left for questions, than a long agenda that nobody can score with confidence.
Use your data
Vendors arrive with beautifully prepared demo environments full of clean, tidy data, and that environment is designed to make everything look easy. I think the single most revealing thing you can do is send each vendor a sample of your own data ahead of time, with the sensitive fields scrubbed, and ask them to load it and run your scenarios against it.
Your chart of accounts, your position control structure, a handful of real employees with messy pay histories and a few vendors with odd payment terms will tell you quickly whether a system fits the way you work or whether it fits only after you change how you work. It also gives you an early preview of what conversion will feel like, because a vendor that struggles to load a small sample in a few weeks is telling you something about how the full migration might go.
Score consistently
A demo without a scoring plan turns into a conversation about which presenter people liked best, and that is a hard result to defend to a council, a board or an auditor. Before the first session, I would build a simple scoresheet that ties each scenario to the outcome you are looking for, define what a strong, adequate and weak response looks like, and walk your evaluators through it so they all read the scale the same way.
It helps to have evaluators score each scenario right after it ends rather than at the end of the day, because by the third vendor, memories blur together and the most recent demo always looks freshest. I also recommend asking people to write a sentence or two explaining each score, because those notes are what you will lean on later when you are comparing finalists or explaining your recommendation to people who were not in the room.
Consistency applies to the vendors too. Give every vendor the same script, the same data, the same amount of time and the same chance to ask clarifying questions, and keep a record of any question you answer for one so you can share it with the others. That fairness protects the procurement, and it also makes the comparison meaningful, because the differences you see are differences in the products rather than differences in how each session was run.
Let users drive
At some point in every session, I like to ask the vendor to hand the keyboard to one of your staff. A presenter who has run the same demo many times can make almost any screen look effortless, and the real question is whether your clerk, your payroll specialist or your department head can complete a basic task without being coached through every click.
This does not need to be elaborate. Ask a user to enter a timesheet, approve a requisition or pull up a budget to actual report, and watch where they hesitate. Those moments of hesitation are useful information about training, adoption and the daily experience your staff will live with long after the selection team has moved on, and in my experience they shape how a team feels about a system far more than any feature list.
Letting users drive also builds ownership. The people who will use the system every day get to see it, touch it and form their own opinions, and when the recommendation comes, it reflects their judgment as well as the project team’s, which makes the rest of the implementation much easier to carry.
Bring it together
When the demos are done, you should have scores tied to your own scenarios, notes that explain them, evidence from your own data and firsthand impressions from the people who will use the system. That is a far stronger basis for a decision than a general sense of which vendor put on the best show, and it gives you a clear record if anyone asks later why you chose what you chose.
If a packaged system cannot handle a scenario that truly matters, the script will surface that early, which leaves you time to decide whether a configuration change, a process change or a small piece of bespoke software is the right answer, rather than discovering the gap after the contract is signed.
None of this is complicated, but it does take preparation, and the agencies that invest a few weeks in writing their own script, preparing their own data and training their evaluators tend to come out of demonstrations with confidence in their choice and a team that already believes in it.
If you want to see how Avero approaches selection from the ground up, start at startatzero.averoadvisors.com.
Planning your next move? Book time with us.