What to ask before your next municipal website.

1. Write a brief around public tasks.

List the questions people bring to the website: collection arrangements, permission for a building project, a meeting agenda, an unexpected closure. Ask service teams which questions repeatedly arrive by phone or in person. Treat those observations as evidence, rather than assuming the most prominent department needs the largest navigation item.

For each important task, write down the starting question, the information needed, the next action and a sensible definition of completion. A permit journey may end at another application system. The website should make that transition understandable, including requirements, costs where known, and who can help.

• Which five tasks most need improvement, and why?
• What evidence would show that a resident can complete each journey?
• Where does the website hand responsibility to a staff member or another system?

2. Budget for content decisions.

A migration is an opportunity to reduce confusion. Inventory pages and documents, then decide what to keep, rewrite, archive or remove. An automated transfer can move text; it cannot reliably decide whether a policy is current or which team owns it.

Ask suppliers to explain how representative content will be checked after transformation. Include tables, long titles, links, documents and translated content. Accessibility work must include the content your team supplies, not only templates.

• Assign an accountable owner to every important service.
• Agree review dates and an approach to expired notices.
• Identify document remediation separately from page design.

3. Evaluate with scenarios, not a feature count.

Ask to observe an editor preparing an ordinary notice and a resident finding the related service on a small screen. Then ask what happens when the editor lacks permission, an integration fails, or a page must be withdrawn. Useful evidence includes recorded test results, a working evaluation environment and clear limitations.

Keep “demonstrated”, “available by configuration”, “custom development” and “planned” separate in your evaluation. A roadmap can inform a discussion, but an uncontracted future feature is not a dependable procurement requirement.

4. Make the operating model explicit.

Self-hosting gives you infrastructure responsibility as well as control. Managed hosting moves some work to a provider, but still needs a clear allocation of duties. Enterprise requirements may apply to either model. Compare the actual responsibility matrix, not just package names.

Identify who monitors the service, applies updates, tests restores, approves access and handles incidents. Ask for the proposed hosting region, subprocessors, support hours, escalation path and recovery approach. Have your procurement and legal teams review the resulting commitments.

• What evidence supports any security or accessibility claim?
• Which response targets are contractual, and which are aspirations?
• Who makes a launch decision, and who can authorize a rollback?

5. Plan the end of the relationship at the start.

Ask how your organization receives its content, media, URL map and operating documentation. Confirm export formats, third-party licence restrictions, transition costs, access arrangements and any deletion duties. Platform intellectual property and municipal content rights are different questions; the contract should address each clearly.

Choose a partner through the quality of the questions they ask, the evidence they provide and the responsibilities they are prepared to put in writing. A polished demonstration is a starting point for evaluation, not evidence of production readiness.