Website Scoping Questions (Internal)¶

Never client-facing. The questions sales works through before a number goes out on a website project: what must be known to price the job, and what must be written down when it is not known. The answers land in the Sales Handover; the price is computed in the cost builder.

This is a scoping document, not a qualification script. Whether a client is one we want is settled by the ICP (touchstone §12); budget and timeline appear here as constraints on the price, never as gates on the relationship.

How to Use¶

Each question is written as it would be said on the call. Under it, in the quoted note, is what the answer moves, what to write down when the answer is "we don't know", and where the artefact itself gets collected later. Ask in whatever order the conversation allows - the sections are a checklist, not a script.

Two rules carry the whole document.

The blocking set stops a quote. Seven questions, listed below. No number goes out while one of them is unanswered. The cost builder enforces the same gate from the other end: it refuses to price until purpose, both Discovery tiers, the surface inventory, the ambition band, the population method, and the Momentum decision all exist.
Everywhere else, "unknown" is an answer - and it becomes an assumption. Write it into the handover's assumptions in the form the list already uses, one clause per bullet: "assumes ~N surfaces", "assumes no authenticated area", "assumes the client populates". That list is the contract between sales and delivery. When reality exceeds it, that is an upgrade conversation with the Decider, priced as the banding delta. Never absorbed, and never a surprise, because it was written down before the quote went out.

Depth is set at the sales moment, never in delivery (process principles). These questions are how the sales moment earns that.

The Blocking Set¶

#	The answer needed	Unlocks
1	The one job the site does above all others	Purpose
2	A sitemap, or a nav we can walk together	The template floor
3	How much is built beyond that list	Flex, and so the surface count
4	Who writes the content, who loads it, roughly how much	Population method
5	Whether there is a secure or logged-in area	Integration register, and the size read
6	Which integrations are in play	Integration register
7	Whether they continue with us after launch	Momentum, or the £1,000 handover

Three further inputs the model needs - the Clarify tier, the Architect tier, and the ambition band - are our calls, not questions we put to the client. They are read off the answers below: stakeholder spread and existing research set the Discovery tiers; guidelines, appetite and the flex answer set the band. The principal owns and approves the count and the band on every proposal.

1. Purpose¶

"If the site could only do one job well, which job is it?"

Moves: the purpose, which is a blocking model input, and the outcome metrics that matter later. Land it on one of the eight: lead generation, customer service and self-serve, brand building, recruitment, content publishing, community and membership, corporate and investor relations, campaign and event. Most sites have one primary and one or two secondary; the primary leads. Blocking.

"What has to be different once this is live?"

Moves: nothing in the price. Record it verbatim - it is the "why they bought" row in the handover, and the Keystone's context input reads it. Do not push for success metrics: per-objective rationale and metrics are what the Keystone is sold to produce. A client who cannot answer is not a gap in the scope; they are the reason Discovery is on the quote.

2. Requirements Provenance¶

"Is there a defined list of requirements? If so, where did it come from, and when?"

Moves: potentially everything, and it is the cheapest question in the document. Requirement lists arrive inherited - an old RFP, a half-finished project with another agency, a board paper, a wishlist from a workshop nobody has revisited. Provenance tells you which items are live and which are fossils.

"Which of those would you drop if it bought you the launch date?"

Moves: the read on what is genuinely fixed. Anything they will not drop is a constraint on scope; everything else is a candidate for the deferred column of the 2.4 scope table.

3. Design and Surfaces¶

"Can you send us your sitemap - or shall we walk your nav together now?"

Moves: the template floor, derived rather than guessed. Deep catalogues collapse hard: hundreds of URLs are usually a dozen templates. Home always counts as its own surface. The cost builder derives templates from a pasted URL list. Blocking. Artefact: the sponsor questionnaire asks for the sitemap or content inventory at 1.1 (section C); this is the earlier, rougher read.

"How much needs building beyond that list - is the site close to what you can point at today, does it need room to move, or is it open-ended?"

Moves: the surface count, via the flex multiplier - close to the list ~1.3-1.6x templates, room to move ~1.8-2.2x, open-ended 2.5x+. Ask it as headroom, never as taste. What it buys is the named variants that let the site flex later without coming back for new design and build. Ask it against the site they want, not the site they have: a recent rebrand, new marketing leadership, or "our sectors all look the same" are cues that a site close to its list today will not stay there. Blocking.

"How many distinct audiences does the site have to serve well?"

Moves: the surface count. Each distinct audience beyond the first tends to demand its own hero and section treatments: +2-4 surfaces each. Ask which ones matter, not which ones exist - a brief that lists six audiences usually has two the site is actually built for.

"Are there separate worlds inside it - divisions, sub-brands, a careers section, investor relations?"

Moves: +3-5 surfaces each. A structurally separate frame, not just a section. Careers is the common one, and it is often where a second platform is hiding - see the next question.

"Is there another site or platform this has to work with - a careers or ATS platform, an intranet, a shop, a legacy microsite?"

Moves: integration lines, cross-domain analytics, and the IA. Ask how seamless the join has to feel: "one experience" is a very different scope from "a link in the nav". A second platform someone else owns is also a second supplier relationship - name it under partners.

"Does marketing run campaign or landing-page programmes on top of the core site?"

Moves: +2-4 surfaces, and it is a strong signal for open-ended flex. The variant count keeps growing after launch.

"Are there any tools or calculators - search, a locator, a configurator, a portal, a gated library?"

Moves: 1-2 surfaces each, and usually an integration line as well.

"Do you already have a design system, and is it in use on something live?"

Moves: an inherited, usable client design system halves the design system line. A library that exists in Figma but has never shipped is not one.

"Does the site serve more than one region or language?"

Moves: the surface count, and the build. Multi-region is a cross-cutting dimension rather than a purpose: a site of any purpose can need it.

Do not ask how many components are needed. Component registries ran 21-65 bloks across sites of near-identical design effort, which is why components do not price: pages predict, part inventories do not. Asking teaches the client that components are the unit of sale, and they are not.

4. Features: The Priced Register¶

Everything here maps 1:1 onto an input in the cost builder, and the hours behind each are canonical in the integration register. Forms, CRM, Search and Maps are single-select - a project takes one row from each, so they cannot stack.

"Which of these does the site need?"

Feature	Options	Notes
Forms	none · native fixed · native client-created · platform (e.g. Typeform)	Client-created is priced because clients ask; we steer away from it
CRM	none · form submission · form output	Submission posts into the CRM; output renders form definitions from it
Search	none · simple · faceted	Faceted adds facets, refinement UI, URL state, sorting
Google Maps	none · single pin · multiple pins · filterable	Filterable adds filter UI and list-and-map sync
Analytics and consent	yes / no	Nearly always yes
Email platform contact submission	yes / no
Gated downloads	yes / no	Requires a form line; flag it if there is none
External data sources	count	Feeds, syndication, anything read from elsewhere

Moves: design and build hours directly. Blocking as a set: the register must be answered, even if the answer is "none of them".

"Is there anything else the site talks to - anything that has to exchange data with another system?"

Moves: a custom integration line, sized by the principal, plus a risk allowance where the API is volatile or undocumented. A volatile custom API is an XL driver in its own right.

5. Features: No Line in the Model¶

These come up on sales calls and have no line anywhere in the pricing model. None of them is refused; none is waved through either. Each is sized by the principal as custom design and build hours, or as a bespoke feature allowance carried through to the 2.4 scope table.

Moves: custom hours. Never quote one of these from memory or by analogy with a past project - the reason they are listed here rather than above is precisely that no calibrated figure exists. Unknown -> if the client is unsure whether they need it, write it into the estimate assumptions as excluded, by name. "Assumes no dark mode" is a sentence that saves an argument.

6. Content¶

"Who writes the content, and when will it exist?"

Moves: the schedule more than the price. Content creation - copywriting, imagery, new-page content - sits entirely with the client. We do not write it, and the proposal should not imply we might. Blocking in combination with the next question.

"How much content is coming across, and who is loading it - you, us, or a script?"

Moves: the population method, a blocking model input: client-populated, all manual, hybrid, or all scripted. Item counts drive the effort. The same 150 items price very differently as one uniform type than as forty bespoke pages, so get the shape, not just the number. Blocking.

"Is any of it being rewritten, or is it lift-and-shift?"

Moves: the population shape, and the realism of the timeline. A rewrite the client has not resourced is the single most common cause of a launch date slipping.

7. Technical Functionality¶

"Are there any secure or logged-in areas? If so, what do they do for the user, and who manages the accounts today?"

Moves: the integration register, build hours, and often the size read. Authentication is not a checkbox on a template - it is a system. Blocking as a yes/no. Unknown -> price the public scope and name authentication as an exclusion in the estimate assumptions.

"Which third-party platforms does the site have to work with - CRM, marketing automation, booking, ticketing, payments, a DAM or PIM?"

Moves: the integration count, and the risk allowance. Ask who owns each contract: a platform the client cannot get admin access to is a delivery risk, not a technical one.

"Is there anything the site must do that it does not do today?"

Moves: catches what the register misses, and often surfaces items from section 5.

8. The Current Estate¶

Facts a client can answer from memory or an invoice. Anything that needs investigating - performance, security posture, accessibility conformance, code quality - is the website audit and roadmap (touchstone §11.1), a gateway product run on the audit kit's strands, not free work on a sales call. "We don't know" here is a product conversation, not a gap - and a client who buys the audit walks into Discovery with its current-state work banked, never re-charged.

Platform or CMS today, and roughly what version
Who built it, and who maintains it now
Hosting: what, who by, what it costs, when it renews
Domain: who owns it, who controls DNS
Whether email runs on the same DNS
SSL and certificates: who holds them
Existing design system or component library
Asset and image library, and whether they own the rights
Incumbent agencies or contractors, and any notice periods

Moves: the population method (a replatform behaves differently from a greenfield build), the migration risk, and the Momentum and hosting conversation. Domains are always registered in the client's name - where we administer them, that is management, never ownership. Say so when the question comes up; it is a differentiator, not a technicality. Email on the same DNS as the site is the classic launch-day incident: flag it at scoping, not at cutover. Artefact: hosting details and access are collected by the sponsor questionnaire at 1.1 (section E).

"Is any particular technology mandated - by procurement, by an existing licence, by your IT team or a group standard?"

Moves: feasibility, and occasionally the whole engagement. A mandate is a constraint to price against; a preference is not. Do not ask which platform they would like: we are Storyblok-first (touchstone §15.2), the stack is our recommendation to make, and asking sells a neutrality we do not practise. Where a client genuinely needs the platform question opened, that is advisory work, priced as such - not a free strand of a website quote.

"Does the site handle any personal or sensitive data - and if so, what, and where does it end up?"

Moves: the integration and risk lines, and whether a DPA and a processor register entry are needed. Both parties must comply with the UK GDPR and the Data Protection Act 2018 under T&Cs 11.1; special category data (health, biometric, political, religious) changes the conversation and should be escalated before quoting.

"Are there compliance obligations we should know about - a public-sector accessibility duty, a sector regulator, ISO or Cyber Essentials in your supply chain, procurement rules, data residency?"

Moves: the accessibility target, the testing matrix, and sometimes the whole timeline. The default commitment is WCAG 2.2 AA, fixed in the Cornerstone. A public-sector duty or a procurement framework can add weeks that have nothing to do with build effort.

"Does your IT function have to sign this off - change control, a security review, a penetration test before go-live?"

Moves: the launch sequence, and sometimes weeks of it. An internal IT governance model, or an outsourced IT provider sitting between us and production, is a delivery constraint that no amount of build effort shortens. Regulated and defence-adjacent clients almost always have one. Where a penetration test is required, ask who commissions and pays for it - it is not carried in the model. Unknown -> write it into the estimate assumptions as excluded, by name.

10. SEO and Analytics¶

"Is anyone doing SEO on the site today - in-house or an agency? If not, is that planned?"

Moves: a relationship to manage, and a migration risk to price. A replatform without a redirect map is how organic traffic gets lost, and the agency that owns SEO will want a say in the IA. Better as an ally named at scoping than a critic discovered at launch.

"What analytics are on the site, and is anyone actually looking at them?"

Moves: the Discovery tier read - a client with no measurement has further to travel in Clarify. Installed-but-ignored is the common answer and is worth hearing in their words. Artefact: the sponsor questionnaire asks this properly at 1.1 (section B), and arranges access (section E). Do not chase access pre-sale.

11. Art Direction¶

"Do you have brand guidelines, and are they current enough to design against?"

Moves: the ambition band, and possibly a prior product. Where guidelines are not solid, that is scoped first - often as an identity round-out - and the client is told on this call, not after the invoice. BXA carries the same precondition. Artefact: guidelines are collected by the sponsor questionnaire at 1.1 (section C).

"Is there an image and asset library we can work from, or does that need commissioning?"

Moves: population effort, and sometimes an art-direction line. Commissioned photography is the client's cost and their lead time.

"Is the brand being adjusted or reworked as part of this?"

Moves: the band, the sequencing, and whether this is a website project at all or a brand engagement with a website attached.

"How much does this need to look like nobody else?"

Moves: the ambition band - System-led, Expressive, or Premium - which is our call, made on this answer plus the guidelines and the flex answer. Do not offer the band names to the client as a menu.

12. Timeline¶

"Is there a date this has to be live by - and what happens on that date?"

Moves: feasibility, sequencing, and sometimes the tier. The "what happens" half is the question that matters: a date attached to an event, a campaign, a funding round, or a contract ending is real; a date with no reason behind it is a preference, and preferences move.

"Between now and then, when are your key people unavailable - holidays, year-end, board cycles, busy season?"

Moves: the schedule, and the realism of every sign-off gate. Our gates need their decisions: design sign-off and UAT both stall without the Decider. Two weeks of August absence in the middle of Validate is worth knowing before it is quoted, not after.

13. Budget¶

"What budget is set aside for this?"

Moves: the tier and band conversation, and whether this is one project or a phased one. A range is a fine answer. Programmes above ~£200k are beyond our current delivery range; that is per programme, not per client.

"Is there contingency, or is the number the number?"

Moves: how variations get handled later. No contingency does not mean no variations - it means every variation is a fresh approval, and the Decider needs to know that now.

"Have you budgeted for year one beyond the build - hosting, licences, ongoing support?"

Moves: the Momentum conversation, before it is a surprise. A client who has budgeted only for the build has not been told what a website costs to run, and that is a conversation we would rather have at scoping than at handover.

How the project is costed is not a client-facing choice and is not asked here. Website projects are fixed price against a fixed scope, which the Cornerstone fixes; blended £140 T&M is the instrument for advisory work and fixed-price work under £10k. Payment stages are the default 30 / 20 / 40 / 10 in payment-terms.md.

14. Partners and Relationships¶

"Who else is involved - other agencies, freelancers, an in-house team?"

Moves: the management line, and the delivery risk. SEO agencies, designers, brand consultancies and in-house developers all need naming. A partner discovered mid-project is a variation; a partner named at scoping is a stakeholder.

"Who holds final sign-off on this?"

Moves: nothing in the price. Everything in delivery. Record the name if they have one; the sponsor questionnaire confirms the Decider formally at 1.1 (section D), and where sign-off sits away from the sponsor, that person attends the workshop and the playback.

"How did you come to be talking to us?"

Moves: nothing in the price. Worth knowing whether this is a competitive pitch, a referral, or a re-approach, and which competitors are named. The handover has a row for it.

"Is this a competitive process? If so, what does it require from us, and by when?"

Moves: the effort of winning, which is ours and unpriced. A formal tender can demand phased pricing broken out by discipline, named references, sector case studies, evaluation against published criteria, and a submission format that has nothing to do with how we price. Find out early: a tender answered in our own format scores badly however good the work is.

15. After Launch¶

"Once it is live, who looks after it?"

Moves: the Momentum decision, a blocking model input. Around 95% of clients continue into a Momentum Partnership, so "yes" is the working assumption - but it must be an answer, not an assumption, because "no" carries a ~£1,000 standalone handover line and 8 hours of codebase cleanup. The handover meeting is the Momentum kickoff; the codebase stays with us. Blocking.

"Would you want us to host it?"

Moves: whether a managed hosting line joins the Momentum quote, sized against a stated usage envelope. Where we host, monitoring and platform health appear in the Playback.

Where Each Answer Goes (Internal)¶

Section	Feeds
1. Purpose	The purpose input; "why they bought" in the handover; the Keystone's context
2. Requirements provenance	The 2.4 scope table's three states, and what to challenge before quoting
3. Design and surfaces	Template floor, the four variant-appetite adds (audiences, worlds, flex, campaign cadence), tools, design system line, multi-region - the surface inventory and so the size
4. Priced register	The integration register, 1:1 with the cost builder
5. Unpriced features	Custom design and build hours, or a bespoke feature allowance; named exclusions in the estimate assumptions
6. Content	Population method and item counts; the schedule
7. Technical functionality	Integration count, risk allowance, size read
8. Current estate	Migration risk, population shape, hosting and Momentum; access is chased later by the sponsor questionnaire
9. Data and GDPR	Risk lines, DPA need, accessibility and compliance targets carried into the Cornerstone; IT governance and security-review constraints on the launch sequence
10. SEO and analytics	Redirect and migration risk; the Discovery tier read; a relationship to manage
11. Art direction	The ambition band, prior products, population effort
12. Timeline	Feasibility and sequencing; sign-off gate realism
13. Budget	Tier and band conversation; phasing; the Momentum opening
14. Partners	The management line; the Decider; competitor hints in the handover
15. After launch	The Momentum decision and any managed hosting line

What This Document Is Not¶

Not qualification. Whether the client is a fit is touchstone §12.
Not the audit. Any question that needs investigating rather than answering belongs to the website audit and roadmap, which is a product.
Not the sponsor questionnaire. That is client-facing, post-sale, and collects the artefacts and the access. This asks only whether they exist and what shape they are.
Not the scope table. The three-state in/out/deferred table is an Architect artefact at 2.4, written against the Cornerstone. These answers feed it; they do not pre-empt it.
Not a promise. Everything answered here is an assumption until the Cornerstone confirms it. Sell the number as an assumption: "assumes ~N surfaces at [band]", and 2.1 trues it up.