The Shopify Scoping Intake Questionnaire: 47 Questions That Prevent Scope Creep

Every agency has a version of this story.

The sales call goes well. The client says "we need a new Shopify store." You send a ballpark. They say yes. You kick off the project — and within two weeks, you're fielding questions your team should have asked before the contract was signed.

"Oh, we also sell B2B." "We forgot to mention — we need French and German." "Our ERP is custom-built and there's no API documentation."

Each of these is a week of unscoped work. Each one turns a profitable project into a breakeven one. And each one was preventable — if someone had asked the right question at the right time.

This page exists because scoping failures almost never happen during scoping. They happen during intake — when the information that shapes the scope either gets collected properly, or doesn't.

Below you'll find a structured intake questionnaire built specifically for Shopify projects: new builds, redesigns, and migrations. It's organised by scope area so you can use it during discovery calls, send it as a pre-call form, or build it into your CRM workflow.

There are two versions:

• The full version — with context on why each question matters and what changes in your scope based on the answer
• The quick copy/paste version — just the questions, ready to drop into a Google Doc, Notion template, or form builder

---

The 47 questions below are organised into 9 scope areas. Each section opens with a note on why that area matters, and each question includes context on what the answer changes in your scope.

You don't need to ask every question on every project. A simple single-market DTC store won't need the B2B or POS sections. But having the full set means you'll never miss a question that turns out to matter — and you'll have a clear record of what was asked and what was answered.

Why this section matters: Before you can scope the work, you need to understand what success looks like to the client. These questions surface constraints and expectations that shape everything else — timeline, budget flexibility, phasing, and what "done" means.

1. What are we building or changing?

New build, redesign, migration, or feature addition. This determines baseline effort, deliverables, and which of the following sections even apply.

2. What prompted this project now?

There's always a trigger — a replatform deadline, a rebrand, a funding round, a seasonal push. Understanding urgency helps you set realistic timelines and identify non-negotiable launch dates.

3. What does success look like in 3 months? In 12 months?

Separating short-term and long-term goals helps you scope phase 1 correctly instead of trying to deliver everything at once. If the client's 3-month goal is "launch and start selling" but their 12-month goal is "expand to 3 markets," you can phase the multi-market work out of the initial scope.

4. Is there a hard deadline? What's driving it?

External deadlines (a trade show, a lease expiry on the old platform, a marketing campaign) are fundamentally different from internal preferences. Hard deadlines may force phasing decisions — it's better to know this upfront than to discover it in week 3.

5. What's the budget range?

Many agencies avoid this question. Don't. A client with £15K and a client with £150K need fundamentally different scopes. Knowing the range early prevents you from scoping work the client can't afford — and prevents them from expecting deliverables their budget doesn't cover.

6. Who are the decision-makers, and how fast can they approve?

Scope documents don't just define work — they define the approval process. If the client has a board that meets monthly, your timeline needs to account for that. If one person makes all decisions, you can move faster. This question also surfaces hidden stakeholders who might change requirements mid-project.

7. Is there an existing site? Can we get access?

For redesigns and migrations, reviewing the existing site is non-negotiable. You'll identify technical debt, content volume, SEO equity to preserve, and integrations you might not otherwise know about.

Why this section matters: Catalogue structure is one of the biggest scope multipliers in Shopify projects. A store with 50 simple products and a store with 5,000 products across 200 collections with complex variant logic are fundamentally different builds — even if the storefront looks similar.

8. Approximately how many SKUs? How many variants per product?

This drives data migration effort, template complexity, collection logic, and testing scope. Shopify has a 100-variant limit per product — if the client's current catalogue exceeds this, you'll need a restructuring strategy.

9. Are there product bundles, kits, or configurable products?

Bundles on Shopify typically require apps (e.g., Shopify Bundles, or third-party). This adds integration work, testing, and potential UX complexity. If the client is coming from a platform with native bundling (like Magento), they'll expect this to "just work."

10. Are there product customisation options (engraving, monogramming, uploads)?

Custom product options go beyond standard Shopify variants. They usually require apps or custom Liquid logic, and they affect the cart, checkout, and order management workflows.

11. How are products organised? What collections or categories exist?

Shopify uses collections (manual and automated), not hierarchical categories like WooCommerce or Magento. If the client expects nested categories, you'll need to explain the difference and plan the information architecture accordingly.

12. Do prices vary by customer group, quantity, or market?

If yes, you're looking at B2B catalogues, quantity breaks, or market-specific pricing — each of which adds significant scope. This is a fork-in-the-road question.

13. Is there existing product data, and in what format?

CSV from the current platform? A PIM? Manual spreadsheets? The quality and structure of incoming data directly affects migration effort. Bad data = longer cleanup = scope creep.

Why this section matters: "How it looks" is where client expectations and development effort most frequently diverge. A client who says "we want something clean and modern" might mean a stock theme with minor tweaks, or they might mean a fully custom design. These questions pin it down.

14. New theme build, existing theme customisation, or migration of an existing design?

This is the single biggest cost variable in most Shopify projects. A new custom theme is 2–5x the effort of customising an existing one.

15. If using an existing theme — which one?

Different themes have different customisation ceilings. Dawn (Shopify's default) is highly flexible. Some premium themes (Prestige, Impulse) have opinionated structures that fight against heavy customisation.

16. How many unique page templates are needed?

Homepage, collection page, product detail page, about, contact — these are standard. But landing pages, lookbook pages, custom campaign templates, and editorial layouts each add design and development time. Get a count.

17. Are there specific UX requirements — mega menus, quick view, sticky cart, etc.?

These features are often assumed ("doesn't every site have that?") but they're real development work. List them explicitly so they're scoped, not discovered.

18. Will you provide the design, or do you need us to design it?

This determines whether your scope includes UX/UI design or just development. If the client has a design team or an external brand agency, clarify handoff format (Figma, Sketch, PDF) and revision process.

19. What's the content situation — do copy and images exist?

Content is the #1 cause of project delays in agency work. If the client doesn't have product photography, brand copy, or page content ready, your timeline needs to account for it — or your scope needs to explicitly exclude it.

Why this section matters: Every integration is a mini-project inside your project. An integration that "just needs to connect" might take 2 hours or 2 weeks, depending on API quality, authentication requirements, and data mapping complexity. These questions prevent nasty surprises.

20. What's the current app/tool stack?

Get the full list: email marketing (Klaviyo, Mailchimp), reviews (Yotpo, Judge.me), loyalty, subscriptions, helpdesk (Gorgias, Zendesk), analytics, etc. Each one needs to be set up, tested, and potentially configured.

21. Which integrations are critical for launch vs. nice-to-have?

Not every integration needs to go live on day 1. Prioritisation prevents scope bloat and gives you phasing options.

22. Are there ERP, WMS, or 3PL integrations?

These are the heavy integrations. Order routing, inventory sync, and fulfilment automation are complex, require staging environments, and often depend on the third party's development timeline — not yours.

23. Any custom integrations or middleware currently in use?

Custom middleware (Celigo, a bespoke Node.js connector, etc.) often needs to be rebuilt or re-pointed for Shopify. This is easy to miss and expensive to discover late.

24. Are there subscription or recurring order requirements?

Subscriptions on Shopify require apps (Recharge, Skio, Loop) and affect checkout, customer accounts, and order management. This is a scope-defining question, not a line item.

25. What payment gateways are required?

Shopify Payments covers most cases, but if the client needs specific gateways (for regional payment methods, B2B invoicing, or instalment plans), it affects checkout configuration and potentially costs.

Why this section matters: Multi-market on Shopify (Markets, Translate & Adapt, or multi-store) is one of the most underscoped areas in Shopify projects. "We sell internationally" can mean anything from "we accept USD and EUR" to "we need fully localised storefronts in 8 languages with market-specific pricing and tax configuration."

26. How many markets do you sell to?

This determines whether you're using Shopify Markets, Shopify Markets Pro, or a multi-store setup. Each has different capabilities and configuration effort.

27. Which languages are required?

Every additional language multiplies content management effort. It also affects theme development (RTL support for Arabic, character handling for CJK languages).

28. Do prices differ by market, or is it just currency conversion?

Currency conversion is simple. Market-specific pricing (different base prices by country/region) is a different feature set entirely and requires manual price management or a pricing tool.

29. Are there market-specific products, collections, or promotions?

Some products may only be available in certain markets (regulatory restrictions, licensing, logistics). This adds catalogue management complexity.

30. What are the tax and duties requirements by market?

Shopify handles basic tax, but complex scenarios (cross-border duties, VAT registration in multiple countries, tax-exempt customer groups) require configuration and potentially third-party tax providers (Avalara, etc.).

Why this section matters: B2B on Shopify has evolved significantly with native B2B features on Shopify Plus, but many agencies still scope it as an afterthought. If B2B is in play, it fundamentally changes the build.

31. Do you sell to both consumers (DTC) and businesses (B2B)?

If yes, are these the same storefront or separate? Shopify Plus supports blended stores with B2B-specific catalogues and pricing, but the setup is non-trivial.

32. How many wholesale customer accounts are there?

This determines migration effort and whether you need company-level accounts with multiple buyers.

33. Do B2B customers get custom pricing, net terms, or volume discounts?

Each of these is a separate configuration area. Custom catalogues, payment terms, and quantity price breaks all need setup and testing.

34. Are there B2B-specific workflows — purchase orders, quote requests, quick reorder?

These features go beyond standard Shopify and usually require apps or custom development.

Why this section matters: If the client has physical locations, POS integration adds an entire workstream — hardware, staff training, inventory sync, and potentially unified customer data across online and offline.

35. Are there physical retail locations? How many?

Number of locations drives hardware needs, staff account setup, and inventory management complexity.

36. What POS system is currently in use?

If they're on Shopify POS already, great. If they're migrating from another system (Square, Lightspeed, Vend), there's a transition plan to build.

37. Does inventory need to sync between online and in-store?

Unified inventory is expected but not always straightforward — especially with multiple locations, warehouses, and fulfilment channels.

Why this section matters: Tracking is scoped last but breaks first. Missing or misconfigured tracking means the client can't measure the ROI of the new site — which erodes trust fast.

38. What analytics and tracking are required?

GA4, Meta Pixel, TikTok Pixel, Google Ads conversion tracking, server-side tracking — list everything. Each needs configuration and QA.

39. Is there a data layer or tag management setup (GTM)?

Custom data layers and GTM containers add setup and testing time, especially for enhanced ecommerce tracking.

40. Are there compliance requirements — GDPR, CCPA, accessibility (WCAG)?

Compliance isn't optional in many markets. Cookie consent, privacy policies, and accessibility standards each have implementation requirements.

Why this section matters: The project doesn't end at launch. These questions prevent the "so who's handling this after go-live?" conversation from happening at the worst possible time.

41. Who will manage the store day-to-day after launch?

This determines whether you need to build for technical or non-technical store managers, and how much training is in scope.

42. Do you need ongoing support or a retainer?

Clarify this before the SOW is signed. Some clients assume post-launch support is included. Others want a clean handoff.

43. Who owns content entry — product data, blog posts, page updates?

If the client's team is entering content, your theme needs to be built for easy content management. If you're handling it, that's scoped work.

44. What's the approval process for design, copy, and functionality?

Single approver or committee? How many revision rounds? This directly affects your timeline buffer.

45. Are there any planned marketing campaigns or seasonal deadlines that depend on the new site?

A Black Friday launch date changes everything about your project plan. Know this upfront.

46. What training does the team need?

Shopify admin training, theme editor training, app-specific training — scope it or exclude it, but don't leave it ambiguous.

47. Is there anything else that keeps you up at night about this project?

The open-ended question. This is where clients mention the thing they've been hesitant to bring up — the political dynamics, the previous failed project, the unrealistic board expectation. Let them tell you.

---

• What are we building or changing? (new build / redesign / migration / feature add)
• What prompted this project now?
• What does success look like in 3 months? In 12 months?
• Is there a hard deadline? What's driving it?
• What's the budget range?
• Who are the decision-makers, and how fast can they approve?
• Is there an existing site? Can we get access?

• Approximately how many SKUs? Variants per product?
• Any product bundles, kits, or configurable products?
• Any product customisation (engraving, monogramming, uploads)?
• How are products organised? Collections/categories?
• Do prices vary by customer group, quantity, or market?
• Is there existing product data? What format?

• New theme, existing theme customisation, or design migration?
• If using an existing theme — which one?
• How many unique page templates needed?
• Specific UX requirements? (mega menus, quick view, sticky cart, etc.)
• Will you provide design, or is design in scope?
• Content situation — do copy, photography, and imagery exist?

• Current app/tool stack? (email, reviews, loyalty, helpdesk, analytics)
• Which integrations are critical for launch vs. phase 2?
• Any ERP, WMS, or 3PL integrations?
• Custom integrations or middleware?
• Subscription/recurring order requirements?
• Payment gateway requirements?

• How many markets do you sell to?
• Which languages are required?
• Market-specific pricing, or just currency conversion?
• Market-specific products, collections, or promotions?
• Tax and duties requirements by market?

• Do you sell DTC and B2B?
• How many wholesale customer accounts?
• Custom pricing, net terms, or volume discounts?
• B2B-specific workflows? (POs, quotes, quick reorder)

• Any physical retail locations? How many?
• Current POS system?
• Does inventory need to sync online ↔ in-store?

• What analytics/tracking is required? (GA4, Meta Pixel, GTM, etc.)
• Data layer or tag management setup?
• Compliance requirements? (GDPR, CCPA, WCAG)

• Who manages the store day-to-day after launch?
• Ongoing support or retainer needed?
• Who owns content entry?
• Approval process — single approver or committee? Revision rounds?
• Planned campaigns or seasonal deadlines tied to the new site?
• Training needed?
• Anything else keeping you up at night about this project?

---

Collecting intake information is only half the job. The other half is turning those answers into a consistent, defensible scope document.

This is where most agencies lose time. The intake answers live in a Google Doc or Notion page. A senior person reads them, opens a blank scope template, and manually decides which sections to include, which deliverables to list, which exclusions to add, and how many hours to allocate. That process takes time, varies by person, and produces inconsistent results.

RuleDox closes this gap.

In RuleDox, each of the intake areas above maps to a scope variable — project type, catalogue size, market count, integration complexity, B2B requirements, and so on. When you set these variables, rules determine what appears in the final scope document:

• A project with 3+ markets? Multi-market configuration sections appear automatically. Single market? They don't.
• ERP integration flagged? Integration mapping, staging environment, and testing deliverables are added. No ERP? Clean scope without unnecessary line items.
• B2B in play? Wholesale account setup, custom catalogue configuration, and payment terms sections are included.

The output is a Google Doc — structured, complete, and consistent — assembled from your rules, not from memory.

The intake questions on this page are designed to capture exactly the inputs RuleDox uses. You can use them independently as a standalone intake framework, or pair them with RuleDox to go from intake answers to assembled scope document in minutes instead of hours.

Once you've collected intake answers, the next step is mapping them to scope variables. See the Scope Variables Checklist →

Try the live demo → — No sign-up required. See how variables produce a real scope document in Google Docs.