All plays

Play 16 · Public records

ForGov-tech vendorsToThe department head

Council funded it Tuesday. The RFP comes later

A seven-step play for a government-technology vendor. It starts from Legistar, stacks BidNet Direct and Firecrawl on top, and ends in a message to the department head that is useful before anyone replies.

Installs this workflow, five project tables and a draft campaign. Source access and any external outputs are checked before research.

Category
Public records
Sources
3
Steps
7

The workflow

  1. TriggerLegistarCouncil votes approving funding for a system
  2. Evidence
  3. Artifact
    What you hand overA peer-purchase pack: four comparable cities that bought the same system, what they paid, their specs, and what they would change.
  4. Contact
    GliderFinds the department head, with a verified work email and a phone
  5. Message
    Send itFrom your own mailboxes, evidence attached

Why it earns attention

Between the council vote and the RFP, the department head has to write a spec for a system they buy once a decade. Peer prices and specs are most useful in exactly that window.

The play in seven steps

  1. 01

    Catch the funding vote

    Legistar
    What you pull
    Council agendas and minutes with an approved item for your category: the city, the amount, the department and the vote date.
    Why it matters
    Money is approved but the RFP is not written. This is the one moment a vendor's input is welcome rather than a lobbying problem.
    Example

    City council, Tuesday · $380,000 approved for a permitting and licensing system · Community Development

  2. 02

    Find peers that bought the same thing

    BidNet Direct
    What you pull
    Awards for the same system in cities of similar size over the last three years: the city, vendor, contract value and term.
    Why it matters
    Peer prices anchor the budget. A department head will read this before they read any vendor's pitch.
    Example

    4 cities of 80k to 120k · contracts between $290k and $610k over 5 years

  3. 03

    Read their specs and what went wrong

    Firecrawl
    What you pull
    Each peer's published RFP, the signed contract, and any staff report or council update about the rollout.
    Why it matters
    Their requirements save weeks of drafting, and the go-live problems are lessons nobody else will hand over.
    Example

    2 of 4 went live late · both cite data migration from the old system · 3 required a public portal

  4. 04

    Build the peer-purchase pack

    Your artifact
    What you build
    A table of the four purchases with price, term and key requirements, plus a short list of what each city said they would change.
    Why it works
    It is useful whether or not they buy from you, which is what makes it safe for a public official to reply.
    Example

    4 peers · price per year · 12 shared requirements · 5 lessons from go-live

  5. 05

    Check before you send

    Check your state's procurement rules before offering anything that could be read as writing the spec. Send facts that are already public and keep the offer to a conversation.

  6. 06

    Find the department head in Glider

    Glider
    Search for
    Community development directorBuilding officialIT directorAssistant city manager
    Why them
    The department head writes the requirements. IT signs off on the technical side and is often the one asked to draft the RFP.
    What you get
    A work email and a direct phone, with the email verified before it goes into a sequence.
  7. 07

    Send the evidence, then run the first test

    • Facts from the data (the number is the step)
    • What you built for them
    • One small ask
    Why it works
    It arrives right after the vote with the research they are about to do themselves. Saying it is theirs either way removes the reason a public official would ignore a vendor.
    First test
    Ten approvals in one category, manually confirmed in the minutes.
    Success looks like
    Three departments accept the pack out of ten votes, and one invites you to an RFI.

The sample message is hypothetical and its numbers are illustrative. Verify every claim, date and rule before sending.

Sources used

The three sources this play names. Each links to the other plays that use it.

All 63 GTM plays

Run this play with Glider.

Deploy the full workflow into a project. Conway checks your scope and source access, builds the evidence, and prepares outreach for review.