Looker RFP Template

Before You Issue a Looker RFP

Looker's leverage is the semantic model: LookML that encodes business logic once so every team's numbers agree. That makes model ownership the central RFP question — who writes it, who reviews changes, and how your own analysts take it over. A vendor that keeps LookML expertise to themselves is renting you dashboards; one that trains your team is building you an asset.

Require performance and governance practices in writing: aggregate awareness and PDT strategy for speed, content governance so explores stay curated rather than sprawling, and a promotion workflow for model changes. Ask how they measure adoption after launch — dashboards viewed weekly by decision-makers, not dashboards built.

What the Looker Sections Cover

• Certified metric definitions and their owners
• LookML structure, git workflow and review rights
• Legacy reports triaged: rebuild, replace or retire
• Explore performance against your warehouse tables
• Embedding, row-level permissions and user attributes
• Licence mix modelled on how people really consume

Writing the Looker Scope of Work

Scope the semantic model by business area and by metric, not by dashboard. State which subject areas the model must cover, which metrics must be defined once and centrally, and where existing definitions conflict between departments, because resolving those conflicts is the work and it requires decisions from people outside the delivery team. Name who arbitrates. A scope that lists dashboards without listing the metric definitions behind them is asking the vendor to invent business logic, and they will, in ways that surface later as disagreements about numbers.

Define the development and deployment arrangement. State whether the model lives in a repository your team can access, what the branching and review process is, who may approve a change to a shared definition, and how changes are promoted to production. Say whether your analysts will develop alongside the vendor during the engagement rather than receiving the model at the end, since concurrent working is the mechanism by which ownership actually transfers. Access design belongs here too, including whether row-level restrictions must reflect who the viewer is.

Scope the performance work explicitly, because it is a design activity rather than a tuning afterthought. State the response-time expectation for the most used content, the data volumes involved, and what the underlying warehouse can sustain. Persistent derived tables, aggregate tables and caching policies all need a design and a refresh schedule with a cost implication, and those decisions should be made against your actual query patterns. If the model sits on a warehouse someone else owns, name the interface and what happens when an upstream table changes shape.

Say what happens to the existing reporting estate, because this is usually left out and usually causes the overrun. State how many existing reports exist, how many are actually used, who decides which are rebuilt and which are retired, and whether the old system is being decommissioned on a date. Define done as adoption and ownership rather than delivery: a named group uses the new content in an existing business routine, your analysts have shipped a model change through the review process unaided, and the legacy reports covered by the scope have been switched off rather than left running in parallel.

Requirements That Actually Separate Looker Proposals

• Model structure for change — ask how the model is organized so that a metric definition change is one edit, and require an explanation of how they avoid the same logic being written into several explores.
• Review and promotion practice — require the code review, testing and deployment process for model changes, including what validation runs before a change reaches users who trust the numbers.
• Derived table strategy — ask which aggregations are materialised, on what schedule, what they cost to rebuild and how a stale or failed rebuild is detected before someone reports from it.
• Row-level security design — where viewers must see different data, require the mechanism in writing and a description of how it is tested, since a permissions error here exposes data rather than merely inconveniencing someone.
• Content governance model — ask how curated, trusted content is distinguished from personal exploration, and who is allowed to publish into the trusted space.
• Embedding requirements — if analytics must appear inside another application or be shared externally, require the authentication, performance and licensing implications to be stated up front.
• Knowledge transfer method — require a specific description of how your analysts learn the model during delivery rather than at a handover session, including what they will have built themselves by the end.

Common Mistakes in Looker RFPs

• ✕ LookML written as a black box no internal analyst can safely change.
• ✕ No performance design, so flagship dashboards take thirty seconds and lose their audience.
• ✕ Explore sprawl: hundreds of unreviewed looks, none of which anyone trusts.
• ✕ Semantic definitions duplicated per team, recreating the metric disagreements Looker was bought to end.
• ✕ Success measured in dashboards shipped rather than decisions supported.

• ✕ Rebuilding the existing report estate faithfully instead of auditing which reports anyone opens, so the project delivers hundreds of artifacts and the conflicting definitions it was meant to end.
• ✕ Scoping the model against a warehouse that is still being built, so the modeling work is done twice as the underlying tables change shape underneath it.
• ✕ Leaving the decommissioning of the previous reporting tool out of scope, which means both licences and both sets of numbers persist and nobody can say which is authoritative.
• ✕ Requiring self-service for business users without scoping the curation, naming and description work that makes an explore usable by someone who does not know the data model.

Questions Worth Asking Looker Vendors

1. Show LookML from a delivered project and walk through its review and promotion workflow.
2. How do you design for performance — aggregate awareness, PDTs, and query-time budgets?
3. What is your content-governance model to prevent explore and look sprawl?
4. How do you transfer LookML ownership: training plan, and what the client changes unaided at handover?
5. What adoption metrics did your last deployment hit at 90 days?

How to Weight the Looker Evaluation

Weight the transfer of model ownership above the volume of content delivered. The strategic value of the platform is a single governed definition layer your own analysts extend; if only the vendor can safely change it, you have bought an expensive report-writing service with a subscription attached. Score the proposed enablement approach, and treat working alongside your team during delivery as materially better evidence than a training module at the end.

Score facilitation ability alongside technical skill, because much of this work is getting two departments to accept one definition of a shared metric. That is a negotiation, and vendors who have run it before will propose a process for it rather than assuming the definitions will be handed to them. A proposal that assumes clean requirements is a proposal that will stall in week three.

Give performance design real weight, since it determines whether the platform is used at all. A dashboard that takes half a minute to load is abandoned quietly and the spreadsheet it replaced comes back. Evidence of designing for query performance at your data volumes, including the willingness to say what the underlying warehouse cannot support, is worth more than breadth of visualisation capability.