Municipal software demos: require vendors to show your actual work

Build the demonstration around a decision

A polished demonstration can show a product's strongest features while leaving the agency's hardest tasks unanswered. Before inviting vendors, decide which operational questions the selection team must resolve. Then write scenarios that let each bidder demonstrate the same work.

GFOA's guidance describes the ERP RFP as a way to define scope and establish accountability. Use that principle to connect requirements, demonstration questions, and the eventual statement of work. Coordinate the approach with procurement so it follows the solicitation and the agency's purchasing rules.

Sources: GFOA — Developing an RFP for an ERP System

Choose scenarios from complete workflows

Ask staff to identify tasks that are frequent, costly to correct, or essential to service continuity. Write each scenario with an input, the user's role, the steps to demonstrate, and the expected result. Include at least one exception that requires a decision or correction.

Use synthetic or approved de-identified records. Vendors need enough detail to prepare a relevant demonstration, but they do not need live resident, employee, or banking information.

• Finance: enter an invoice, route approval, issue payment, and show the ledger entry.
• Payroll: process an approved retroactive change and explain the result.
• Utility billing: correct a reading, recalculate the charge, and show the adjustment history.
• Permitting: return an incomplete application, receive corrected plans, and show the applicant's status.
• Reporting: produce a required report and trace an amount to its source transactions.

Ask the vendor to classify how the result is delivered

When a scenario succeeds, record the product and module used. Ask whether the function is standard, configured, customized, supplied by another provider, or dependent on a future release. Capture associated licensing, implementation, and maintenance assumptions.

A capability available in another module may be useful, but it belongs in the cost and scope comparison. A future feature requires a different assessment from a feature demonstrated in the proposed version. Avoid recording both simply as 'yes'.

Evaluate the work using agreed criteria

Set criteria and weights before evaluation as required by the procurement process. Assess completion of the scenario, staff effort, access controls, exception handling, reporting, and the implementation work needed. Use the same scoring guidance across evaluators.

Have evaluators record observations individually before discussing scores. Separate what the vendor demonstrated from what the team inferred. If clarification is needed, procurement should manage it consistently and document the answer.

Practical follow-up may include a second demonstration, an approved reference check, or a representative report export. The solicitation determines which follow-up activities are allowed and how they affect evaluation.

Assess accessibility and integrations directly

Ask the proposed team to demonstrate keyboard use, meaningful error messages, and the accessibility of forms and generated documents. Review the supplier's accessibility documentation and the actual product together. The agency should identify the standard and contract requirements that apply.

For integrations, ask for the proposed method, licensing, data ownership, failure monitoring, and responsible team. A diagram with a connection line is not enough to establish that an interface is included or ready to operate. Require a clear scope and acceptance scenario.

Carry the findings into the agreement

After selection, reconcile the requirements, demonstrated capabilities, proposal, and statement of work. Resolve contradictions before signing. Record the modules, interfaces, reports, conversions, training, and acceptance tests the agency is purchasing.

Review gaps explicitly. Some may be acceptable process changes. Others may create recurring manual work or extra cost. Name the owner who accepts each gap and explain its operating effect to leadership.

• Retain scenario results and permitted evaluation records.
• Confirm implementation estimates reflect the demonstrated workflows.
• Define acceptance with expected outputs and responsible agency reviewers.
• Document any dependency on another supplier or future product release.

Prepare the first script with the people doing the work

Start with a transaction staff find difficult today. Ask them to describe how it begins, where it gets stuck, and what a correct result looks like.

A well-written scenario makes the demonstration useful to frontline staff and senior leaders at the same time. Staff can assess whether they can complete the job; leadership can assess the effort, cost, and unresolved risk.