The RFP mistake every municipality makes on a website rebuild

The RFP describes a product, not a result

We read a lot of municipal website RFPs across New Brunswick, Nova Scotia and Prince Edward Island, and most of them share the same shape. There is a list of required pages. There is a named content management system, or a short list of acceptable ones. There is a requirement for a news section, a calendar and a staff directory. There is a launch date, often tied to a council term or a budget year.

What is almost never there is a statement of what the website is for.

That sounds philosophical. It is not. A municipal website exists to let residents do things without phoning the office, to meet legal obligations around language and accessibility, and to give council a channel that staff can actually maintain. If the RFP does not say that, bidders will not price for it. They will price the page count.

The result is predictable: three bids that look the same, scored on design samples and a demonstration, and a site that is handsome on launch day and stale within eighteen months.

Write the RFP around decisions and measurement

Start with the questions the website has to answer, and the actions it has to complete. For most municipalities in Atlantic Canada, the list is short and boring, which is exactly the point:

• Pay a bill, a ticket or a permit fee.
• Report a problem (a pothole, a streetlight, a missed collection) and get a reference number.
• Find out when garbage and recycling are picked up at a specific address.
• Find a council meeting, its agenda and its minutes, in both official languages.
• Apply for a permit, a licence or a rental of a municipal facility.
• Find who to call for a specific department, and when they are available.

Now attach a measure to each one. Not an impression count. A completion. How many bill payments were made online versus at the counter? How many service requests arrived through the site versus the phone? How long did the average resident spend finding collection day?

If you write those into the RFP as the primary evaluation criteria, you change the conversation. Bidders have to explain how their proposed build will move those numbers, and how they will prove it. The ones who cannot answer will self-select out, which saves everyone a demonstration.

What to ask bidders instead of “which CMS”

You do not need to name the platform. You need to describe the constraints and let bidders defend their choice. The questions that separate serious vendors from template shops are the ones about what happens after launch:

1. Who updates a page on a Tuesday afternoon? Ask for a walkthrough of a staff member with no technical training publishing a road closure notice in English and French. Ask how long it takes.
2. What breaks when a staff member leaves? Ask how permissions, training and documentation are handled, and whether the municipality owns the site, the content and the domain outright.
3. How is the site measured? Ask what analytics are installed, who reads them, and what the vendor would report to council quarterly if asked.
4. What does year three cost? Not the build. The licensing, hosting, security patching, plugin updates and the hourly rate for changes that fall outside the plan.
5. What are the exit terms? Can you export everything and move to another provider without starting over?

A bidder who answers those clearly is telling you more than any design portfolio can.

What “hosting and managed IT” should actually mean

This line item hides more risk than any other. “Hosting included” can mean a managed environment with backups, monitoring, uptime commitments, security patching and a named person who answers the phone. It can also mean a shared server somebody set up once and has not looked at since.

Write the RFP so that bidders have to spell it out. Where is the site hosted, and in which country? (Data residency matters to a public body, and counsel will have a view.) How often is it backed up, and has a restore ever been tested? Who applies security updates to the platform and its plugins, and how quickly after they are released? What is the response commitment when the site is down on a storm day, which in this region is when residents need it most?

If the bidder is subcontracting hosting to a third party, ask who holds the relationship and who you call. There is nothing wrong with that arrangement, but you should know it before you sign.

Accessibility and bilingual requirements are not add-ons

New Brunswick is Canada’s only officially bilingual province, and municipalities there carry language obligations that a vendor from outside the region may not fully appreciate. Beyond that, accessibility expectations for public-sector websites are rising everywhere, and the Web Content Accessibility Guidelines (WCAG) are the reference standard that most procurement language points to.

Both of these fail in the same way: they get listed as a requirement, the bidder ticks the box, and nobody verifies anything until a complaint arrives.

Put teeth in the RFP. For accessibility, name the WCAG version and conformance level you require, ask for an audit at launch by someone other than the builder, and ask how new content will be kept compliant after launch (alt text, document formats, video captions). A beautifully accessible template is undone by one scanned PDF of a council agenda.

For bilingual delivery, require parity, not a translation layer bolted on afterwards. Every page, form, error message, confirmation email and PDF should exist in both languages, be published at the same time, and be navigable in either language without dropping back to English. Ask who translates, who reviews, and how the workflow prevents a French page from lagging weeks behind its English counterpart. Confirm the specifics of your obligations with your own counsel, because they vary by municipality and by the kind of content.

The maintenance trap

The expensive part of a municipal website is not the build. It is the decade after.

In our experience, the sites that fail do so slowly. A plugin is not updated and a form stops working. The staff member who knew the CMS moves on. The French version falls behind. The events calendar fills with items from two summers ago. Eventually someone proposes a rebuild, a new RFP goes out with the same page list, and the cycle restarts.

The way out is to treat maintenance as a deliverable in the original RFP. Specify a content ownership model (which department owns which section, and who reviews it on what schedule). Specify a training plan with a refresher after staff turnover. Specify a quarterly review that looks at the completion numbers from the first section of this article and asks what should change.

A website that staff cannot maintain is not an asset. It is a liability with a launch party.

What to do first

Before you draft anything, pull the last six months of phone and counter traffic from the departments that take the most resident contact. Sort it by request type. The top ten reasons people call your office are the top ten things your website has to do without them calling. That list, with a measure beside each line, is the core of your RFP. Everything else, including the technology, follows from it.