---
title: "RFP language for procuring a public art guide"
description: "Copy-ready requirements language for procuring a map-first public art guide: scope, catalog standards, data ownership, accessibility, and operations."
kind: "Template"
updated: "2026-07-29"
source: "https://www.civiccollection.com/toolkit/rfp-language-for-procuring-a-public-art-guide"
---

# RFP language for procuring a public art guide

> Copy-ready requirements language for procuring a map-first public art guide: scope, catalog standards, data ownership, accessibility, and operations.

Kind: Template  
Updated: 2026-07-29  
Source: https://www.civiccollection.com/toolkit/rfp-language-for-procuring-a-public-art-guide

Most procurement offices have never bought a public art guide, so the RFP
usually gets assembled from a website template and a GIS template, and the
result invites the wrong bids. This template is the requirements language we
would want to answer: specific enough to filter out mismatched vendors,
neutral enough that any serious one can respond honestly. Lift the sections
you need, replace the bracketed placeholders, and delete anything that
doesn't apply to your program.

Two notes before the language. First, decide whether you're running a
[request for proposals](https://www.civiccollection.com/glossary/request-for-proposals) or starting with a
[request for qualifications](https://www.civiccollection.com/glossary/request-for-qualifications); for a
service like this, an RFQ shortlist followed by interviews often gets better
answers than a cold RFP. Second, write requirements as outcomes ("visitors
can follow a tour on their phone") rather than implementations ("native
mobile application"), so you can compare genuinely different approaches. Our
guide to [evaluating public art mapping software](https://www.civiccollection.com/blog/how-to-evaluate-public-art-mapping-software)
walks through the vendor categories these requirements will attract.

## Background and purpose

Give bidders the facts that drive scope, because vague background produces
padded pricing.

> [Organization] stewards a collection of approximately [N] works of public
> art, including [murals, sculptures, memorials, and temporary
> installations], across [geography]. Records are currently held in
> [spreadsheets / a legacy database / PDF documents / an open dataset at
> URL]. Approximately [N] works have current photographs. The purpose of
> this procurement is a public, map-first guide to the collection and the
> catalog that sustains it.

## Scope of work

> The successful proponent will deliver: (a) a public web guide to the
> collection, opening on an interactive map, with a page for every work;
> (b) a collections catalog and administrative interface through which
> [Organization] staff manage records and publish updates without developer
> assistance; (c) migration of existing records and images into the catalog;
> and (d) ongoing hosting, maintenance, support, and improvement of the
> guide for the term of the agreement.

## The public experience

> The guide must work in any current web browser on a phone, tablet, or
> desktop, with nothing for visitors to install. Each artwork must have its
> own page, with photographs, artist credit, and interpretive text, at a
> stable link that can be shared, cited, and indexed by search engines.
> Visitors must be able to browse the collection on a map, filter it, and
> follow [self-guided tours](https://www.civiccollection.com/glossary/self-guided-tour) with walking
> directions between stops.

## The catalog

This is the section most templates omit, and its absence is how a
ten-year collection ends up inside a tourism widget. Standards here protect
the record, whoever holds it next.

> Collection records must follow recognized museum documentation practice
> (for example CDWA/CCO, SPECTRUM, and the Getty vocabularies), including
> structured artist attribution, controlled vocabularies for object types
> and materials, [accession](https://www.civiccollection.com/glossary/accession) identifiers, location
> history, and [condition reports](https://www.civiccollection.com/glossary/condition-report) with dates.
> The proponent must describe how records are versioned and how the catalog
> supports works entering, moving within, and leaving the collection,
> including [deaccession](https://www.civiccollection.com/glossary/deaccession).

## Data sources and migration

> The proponent must describe the migration process for the record sources
> listed above, including how duplicates, conflicting fields, and missing
> data will be handled and reported. Where [Organization] publishes
> [open data](https://www.civiccollection.com/glossary/open-civic-data), the guide should read from or
> reconcile against it so civic geography and registry data stay current.

## Community contributions

> The guide should accept public contributions such as photographs,
> stories, and suggested corrections. All contributions must enter a
> moderation queue; nothing may publish without approval by [Organization]
> staff. The proponent must describe the moderation workflow and how
> contributors are credited.

## Data ownership and export

> All collection records, images, and contributed content remain the
> property of [Organization]. The full catalog must be exportable in open,
> documented formats at any time during the term and at termination,
> without additional fees. The proponent must describe the export formats
> and demonstrate an export during evaluation.

## Accessibility

> The public guide must conform to WCAG 2.1 Level AA, and the proponent
> must state how conformance is tested and maintained as content changes.

For United States state and local governments, the Department of Justice's
ADA Title II web rule sets WCAG 2.1 AA as the technical standard for public
web content, with compliance dates in 2027 and 2028 depending on entity
size; confirm how the rule applies to your entity and note it here if it
does. Canadian programs should reference the accessibility statute in force
in their province.

## Hosting, operations, and support

> The proponent will host and operate the guide for the term of the
> agreement, including security updates, backups, monitoring, and support
> with named contacts and stated response expectations. The proposal must
> price one-time onboarding (design, setup, migration) separately from the
> recurring operating fee, and must state what happens to the guide, the
> data, and the domain at the end of the term.

## Reporting

> The system must provide reporting suitable for program accountability:
> the condition and care posture of the collection, contribution and
> moderation activity, and public engagement with the guide. The proponent
> must show these reports from a live deployment during evaluation.

## Evaluation

Ask every shortlisted vendor for the same three things: a walkthrough of a
live deployment serving a real collection, a sample export of a real
record, and references from the staff who maintain the catalog day to day
rather than the staff who bought it. Weight the ongoing relationship
heavily; the build is the short part of a guide's life, and most of what
this document protects only matters in year three.

Adapt freely. A short RFP built from the sections your program actually
needs will serve you better than a long one assembled to look thorough.

If you'd like to see how we answer language like this, [book a demo](https://www.civiccollection.com/demo)
and score a live guide against your own requirements.