How To Build Your Municipal RFP For Reporting Software [Template]

If you are a municipal or state-level organization looking for software to help you manage your reporting process, chances are you have to put out a request for proposal (RFP). But do you know what

Co-Founder & Alabama Native


If you are a municipal or state-level organization looking for software to help you manage your reporting process, chances are you have to put out a request for proposal (RFP).

But do you know what components your potential vendors need to see? And beyond that, do you know how to manage your RFP after you send it out?

This article outlines both of these processes—from start to finish. The first part of the article explains six things you should include in your RFP template for software, and the second part gives you the steps necessary for the RFP procurement and management process.

Download Now: 143 Local Government KPIs & Scorecard Measures

Note: Your approach to a government RFP template may differ from our suggestions below based on your specific circumstances (and you likely already have a legal team that is well-versed in putting together the actual proposal with the necessary legal jargon), but these recommendations should help you get started and point you in the right direction.

Part I: Writing Your Municipal RFP Template For Software

1. Executive Summary

The executive summary—typically just a page long—helps the software provider understand what your problems are and whether or not their software will meet those challenges. You want your municipal RFP to weed out companies that give out generic responses, and don’t seem to care about or understand your cities problems or challenges. It is a great way to figure out whether the responding organizations really understand the situation you’re in. Bear in mind that an executive summary can look crisp and clean, but still not be relevant to the particular set of challenges your municipality is facing. So, make sure the response is well thought out—not just a cookie-cutter, “reply-all” response.

2. Software Requirements

You’ll want to list out the software requirements your company considers vital, and then ask the respondents to describe in detail how they’ll be able to meet your needs. It’s important to allow for (and even encourage) the responder to show you how the needs will be met, either by specific example or through actionable, detailed language. Hint: Allow responses such as “By default,” “Can be configured,” or “Partially meets the requirement,” so vendors do not default to “Yes” to all questions.

3. Company History

This is a good place to ask about how long the company has been in business, their approach to software, financial soundness, etc. You’ll want to learn if the organization is dedicated solely to their software solution, or, for example, if they are primarily a consulting firm whose piece of software doesn’t comprise a large part of their business model. You’ll also want to find out whether there have been a lot of changes to the company’s structure in the last few years. If they’ve recently had a major shake-up of leadership or they’ve recently been acquired, those may be red flags to watch out for.

4. References

You will want to be on the lookout for current happy customers, disgruntled former customers, and both recent and long-term customers. People who have been using the software for a long time might be able to tell you more about how the software has evolved and how the customer support process works. References that are less than six months old can give you a better look into the onboarding process. Of course, any negative reviews should be taken into account, as well. Be sure they provide you with relevant, municipal references, so you get an accurate depiction of how it may work for you. Hint: Be sure you ask for both phone numbers and emails, so you’re sure to get in contact with their references no matter what.

5. Price

The more clearly you can define what price range you’re looking for, the better. You need to be able to provide the vendor with information about training, support, setup and data entry, the number of licenses you’ll need, and a payment schedule. (The key here, in my opinion, is to have more than a few categories and to be as specific as you can.)

The value that comes out of the price section of your RFP for software is being able to compare apples to apples. If you ask only for license prices, you may find that one organization is selling the licenses at a very low cost, but they have steep costs elsewhere. Or, if you ask for all of the costs as one lump sum, you may not find out that one of the vendors has made some assumptions about training process costs that another organization hasn’t—and if that cost isn’t accounted for, then you’d have to add that on later. So, the best way to compare software packages is to get a comprehensive look at all the prices, all at once.

6. Other

You may want to consider having an “Additional Information” section. This allows a vendor the room to put in any information they think will separate themselves from the crowd. This also gives each software provider a place to write in a qualitative description of how their pricing works to accompany the quantitative numbers from the “Price” section.

Part II: Managing Your Municipal RFP Process For Reporting Software

Congrats! You’ve completed your request for proposal (RFP) template for software, and it’s now time to send it out to your top software vendors. That’s great!

But as much as you’d like to sprint toward the goal of a quick software implementation, hold up for a moment. There’s something vitally important that you can’t afford to miss: defining the software procurement process, start to finish. This typically involves creating a schedule by which responses to your RFPs are due, then including that schedule in your government RFP template and sticking by it. That sounds simple enough—but anyone in local government can tell you that this process can be anything but simple.

What often happens is that the performance management office doesn’t realize how time-consuming (or in-depth) the procurement process needs to be, so they don’t budget enough time or resources. For instance, a municipality could be asking for total responses right away—within a week or so—instead of allocating a chunk of time for questions. This can lead to a big headache or worse—a software purchase from a vendor that simply can’t help you.

So here’s the point: even if you have a rock-solid RFP, you still need to ensure that your process runs smoothly. To help you out, I’ve outlined my recommended approach. Let’s take a look:

1. Response Of Interest

Once you’ve issued your RFP to the top software vendors you’re interested in, try to prompt organizations to respond with interest in the first two weeks. Most organizations will be able to respond with their interest in a much quicker time frame, but this two-week window is dual purpose—it is also used as a “question period” (which is our next step).

2. Question Period

Like I mentioned, if the vendors have any questions during the first couple of weeks, be sure to respond to them promptly and thoroughly. Anyone who responds from the vendor organization during the two-week period can be considered a point of contact; be sure to note this person’s contact information in case your RFP changes for any reason.

For instance, let’s say I’ve received my responses, and I’ve gotten a lot of questions about training. That may help me realize that I need to put out an addendum for this RFP. Or perhaps things are so complicated that I need a separate RFP for a particular scope of work. Getting clarity now will ensure this process runs smoothly. Be sure to send all questions and answers to anyone who has expressed interest, even if they did not submit the questions.

3. Responses Due

You should probably allow 2-3 weeks after the question period for the software vendors to respond. Ideally, an RFP should require separate pricing and technical responses. It’s important to grade the responses based on predetermined criteria to narrow your choice of vendors down to a final group of 2-4.

Most responses are due at a particular time and particular location, with no exceptions. That’s fine, but if FedEx doesn’t deliver to the location, be sure to note it in the RFP. Expect quality vendors to send their responses a day ahead of time. Some organizations will review the responses to see if there are any missing parts and give vendors a chance to send in the missing pieces, so decide in advance if you want to allow for that.

4. On-Site Presentations

At this point, you can ask your favorite vendors to provide on-site presentations. (Typically, this only happens if your RFP is for more than $10,000.) The only way to fairly and adequately judge which reporting software solutions are going to work well for your business is to compare apples to apples. So, give each vendor the same example and have them use that example to demonstrate their software.

Make sure that upper management has defined the criteria by which these presentations are judged. If you skip this step, you’ll be doing your organization a huge disservice by allowing subjective judgments to creep into an important business decision.

Ask the vendor to ensure that the person who will be doing the setup and training is at (or is giving) the presentation. Give him or her the predetermined sample information for their live demo. You should use this time to not only learn about their product, but also to judge the vendor contact you’ll be interacting with regularly.

Pro Tip: If you don’t “click” with the vendor contact—or this individual seems unenthused, or simply unprofessional—proceed with caution. You want to be sure that your point of contact with the software vendor is a good cultural fit with your company! (See this article—specifically #5—for more information.)

5. Final Judgment

Once you’ve evaluated your favorite software vendors through their on-site presentations, it’s time to make your final judgment. You will need to weigh and balance price, functionality, and the cultural fit of the software company. Our suggestion is to decide upon this balance beforehand. A solid breakdown might look like:

  • 50% Functionality
  • 25% Price
  • 25% Software Company Cultural Fit

Eventually you’ll need to decide if the cheapest software that meets, let’s say, 80% of your needs is better than a software that meets 100% of your needs, but costs 50% more.

Remember, the price may be quite appealing, but you’re going to want to know if a company founder just left, if they’re losing money left and right, or if you hated the people you interacted with. These are all signs of trouble in scorecarding paradise, and you may want to avoid working with such companies.

A few pieces of advice...

It’s not simply having a municipal RFP for software that is critical—it’s having software that supports your management process and strategy. The last thing you want is to purchase a piece of software that doesn’t meet your needs from a company you’re not comfortable working with, just because they had the lowest price or the quickest integration. In other words, just because the software fits your budget or a vendor has provided you with a shiny proposal doesn’t mean that’s the solution you should select.

One way to ensure you end up with the right software is to talk about and agree upon every element that goes into your RFP for software and make sure everyone involved understands the steps in your procurement process. If you do this, not only will your software vendor understand what you require of them, but your executives and team members will be more prepared when you get the new system. Best of luck!

How To Build Your Municipal RFP For Reporting Software [Template]