A Municipal RFP Checklist for Meeting Livestreaming

A municipal RFP for meeting livestreaming usually gets written by adapting whatever the last vendor's contract said, which means it inherits that vendor's gaps along with its terms. The fix is a checklist written from the buyer's side: what to specify so that every bid answers the same questions, in the same terms, and the lowest number on the page is not hiding the weakest plan.

Here is what to put in the solicitation, in the order it usually needs deciding.

1. Camera coverage and positions. Specify the minimum number of camera angles the chamber needs, not just "video coverage." A single fixed wide shot of the dais is a different bid than coverage of the dais, the podium, and the audience during public comment. Name the positions you expect covered and let vendors bid against that, not against their own default.

2. Audio pickup for public comment specifically. The dais microphones are usually fine. Public comment, from a podium or a handheld mic passed through the audience, is where audio actually fails, and it is the section most likely to get requested later. Require the bid to describe how it handles audio from the floor, not only from the dais.

3. A documented failover plan. Ask every bidder to describe, in writing, what happens if the internet connection drops mid meeting: whether the meeting keeps recording locally regardless of the stream's status, what the backup connectivity path is, and who has the authority to activate it. A bid that answers this in one confident sentence with no detail behind it is a bid worth a follow-up question.

4. Recording format and delivery timeline. Specify the file format you need, matched to what your clerk's office and website can actually play, and specify a delivery deadline measured against your own schedule rather than the vendor's convenience. If minutes get drafted the morning after a meeting, the recording needs to already be in hand that night.

5. Retention policy. This is a records question for your clerk or records custodian, not a technical spec, so answer it before writing the RFP rather than leaving it to the vendor to guess. Specify how long recordings must be kept and in what form, matched to your body's own records schedule, and require the bid to confirm it can meet that schedule.

6. Insurance requirements. Require proof of general liability and equipment coverage, with a certificate of insurance issued to your municipality before the vendor is on site, not a promise of coverage described in a sales conversation. We keep a W-9 and certificate of insurance ready to send the same day a procurement office asks, the same practice a solicitation should require of any bidder.

7. Response time during a live meeting. Specify a maximum time the vendor must answer if something goes wrong while the meeting is live: a dropped stream, a failed microphone, a camera that stops responding. A bid with no answer to this question is a bid that has not thought about the night something actually breaks.

8. The same crew, meeting to meeting. Ask whether the vendor commits to sending the same operator or team each month, or whichever staff happens to be free that week. Continuity is worth naming explicitly in the RFP, because it is easy for a bidder to promise verbally and quietly drop once the contract is signed.

9. A site visit before the bid is finalized. Require bidders to walk the chamber before submitting a final number. Power, existing sound system, hardline availability, and sightlines are all room-specific, and a bid written without seeing the room is a guess dressed up as a number.

10. Captioning, specified explicitly if your body needs it. If your board or council has decided captions are required, on the live stream or the archived recording or both, put that requirement in the solicitation directly rather than assuming every bidder offers the same thing by default. Vendors vary widely here, and the difference is usually invisible until the first meeting a resident actually needs it.

11. Ownership of the equipment and the files. Specify who owns the installed equipment if the contract is for a fixed system, and specify who holds the master recording files if the contract ends or is not renewed. Both should be answered in the contract itself, not assumed.

12. Escalation path. Name a specific point of contact and a specific backup for that contact. "Call our office" is not a plan when the office is closed and the meeting is starting in ten minutes.

13. How the bid will be scored. State in the RFP itself whether price is the only factor or one of several, and if it is one of several, say which questions above actually count toward the score. A vendor who reads that camera coverage, failover, and response time are evaluated alongside price will answer them properly instead of treating them as filler before the number that matters.

Score the answers to items one through twelve against each other line by line before looking at price at all, then bring price back in once the plans are actually comparable. Two bids that look close on paper can represent very different levels of coverage once the failover plan and the audio pickup answer are read closely, and the RFP process only works if someone actually reads them rather than sorting by the bottom line.

None of this requires a legal background to write. It requires deciding, in advance, what a working relationship with a vendor is supposed to guarantee, and putting each guarantee in writing before the contract is signed rather than discovering the gap during a live meeting. Our government page describes how we answer each of these when we bid on this kind of work, our trust center has the documentation a procurement office typically asks for, and our post on the failover and hand-off schedule behind a recurring meeting stream goes deeper on items three and four above.