Analytics dashboard RFP: the pack for one dashboard that shows leads, cost and revenue

Scope this as building one dashboard that consolidates marketing performance across the platforms you name, most commonly GA4, Google Ads, and a CRM, into leads, cost, and revenue figures a non technical person on your team can read without asking someone to explain it. It is not a rebuild of your tracking; if GA4 or your ad account tracking has known gaps, fixing those is separate work that should happen before or alongside this build, not be discovered by it.

Name the specific metrics you actually want to see: cost per lead, cost per acquisition, return on ad spend, or revenue by channel, rather than asking for "everything" and hoping the vendor guesses correctly. A dashboard built without a clear list of required metrics tends to either miss what you actually needed or bury it under metrics nobody looks at.

State whether this is a one time build or an ongoing engagement that includes updates as your business or your tracking changes; those are different commitments with different pricing.

Grant read access to GA4, your Google Ads account, and your CRM, or whichever specific platforms you named in scope, so the vendor can see the raw data before deciding how to connect it. Building a dashboard's connections without ever looking at the underlying data first tends to produce a dashboard that technically pulls numbers but gets the meaning wrong.

Provide any existing metric definitions or reporting conventions your team already uses informally, since a dashboard that redefines "lead" differently from how your sales team already uses the word creates confusion rather than clarity.

If offline conversion import from your CRM into Google Ads is part of the scope, provide access to whatever field in your CRM marks a deal as closed won, since that field becomes the trigger the whole import depends on.

The dashboard itself, typically a Looker Studio report or similar, should live under your own Google account, not the vendor's, so you retain access and editing rights regardless of whether the engagement continues. Confirm this explicitly, since some vendors default to building inside their own account and sharing a view only link, which stops working the moment the relationship ends.

The metric definitions document belongs to you and should be detailed enough that a different analyst or vendor could recreate the same logic without starting from scratch. Vague documentation here is a common way a dashboard quietly becomes unmaintainable once the original builder is gone.

Ask what happens to any data connectors or scheduled data transfers set up to feed the dashboard if you change vendors, since some connector tools are billed to the account that created them, not automatically to yours.

Set a first milestone around the metric definitions document alone, reviewed and approved by your team before any dashboard building starts. Agreeing on what a lead and a conversion actually mean before building the dashboard avoids a rebuild later when the definitions turn out to be wrong.

Set a second milestone for a working draft dashboard, checked against each source platform's own native reporting for an identical date range. Any mismatch should be explained and resolved before the dashboard is considered accurate, not waved away as a rounding difference.

The final acceptance test is a live walkthrough where your team asks the dashboard the actual business questions it was built to answer, such as which channel produced the cheapest lead last month, and gets a correct, explainable answer.

Weight accuracy and clarity over visual polish: 25 percent for a proposed process to write and validate metric definitions before building anything, 25 percent for experience connecting the specific platforms you named, 20 percent for a plan to reconcile dashboard numbers against each source platform, 15 percent for price, and 15 percent for a sample dashboard, viewable, not just described.

A proposal heavy on visual design language and light on how metrics will be defined and validated is a warning sign; a beautiful dashboard showing the wrong numbers is worse than an ugly one showing the right numbers, since the wrong numbers get trusted and acted on.

Ask to see a redacted sample dashboard from past work, and ask specifically how that client's metric definitions were decided, since the answer tells you whether the vendor treats definitions as a real step or an afterthought.

Collect a written answer to each of these before you compare bidders: How will you define a lead, a cost, and a conversion for our specific business before building anything? What is your process for checking dashboard numbers against each source platform's own reporting? How often will the dashboard refresh, and is that frequency actually necessary for how we make decisions? Who owns the dashboard account and the underlying data connectors once the build is complete?

Also ask what happens if one of the source platforms, GA4, Google Ads, or the CRM, changes its data structure or API, since a dashboard with no plan for that eventuality can silently break or show stale numbers with no obvious warning.