# How to Run Client Discovery for Shopify Projects

> A client discovery process for Shopify agencies that survives real clients: what to ask before quoting, how to structure sessions, and when to stop and start building.

_Published: 2026-07-24 · CommerceCopilot_

## Why most client discovery processes fall apart

Ask ten Shopify agency owners how they run discovery and you'll get ten different answers, and most of them will admit the real answer is "it depends how busy we are that week." A shopify project discovery process either gets compressed into a single 45-minute call before the quote goes out, or it sprawls into weeks of open-ended conversation that never quite resolves into a scope. Neither version survives contact with a real client: one produces a quote built on guesses, the other produces a stalled deal.

A client discovery process that actually holds up has three properties. It gathers the right information in the right order, before anyone commits to a price or a timeline. It produces something a developer can act on, not just a folder of call notes. And it stays open to new information instead of freezing the moment the kickoff call ends, because clients keep changing their minds after the contract is signed, not just before.

## What discovery is actually for

Discovery is not a formality before the "real" project starts. It's the phase where you convert a vague client ask ("we want the site to feel more premium and convert better on mobile") into something specific enough to scope, staff, and estimate. Skip it, or rush it, and every downstream role pays for it: the developer builds against assumptions, the account manager fields change requests that feel like scope creep but are really unasked questions, and the project's margin erodes one "quick clarification" at a time.

Shopify's own partner guidance on running discovery sessions recommends structuring the conversation in stages, from the client's organizational goals, down to departmental goals, down to the individual stakeholder's personal stake in the project, and matching the time you spend to the complexity of the work: consider two half-day sessions instead of cramming everything into one long day, so people stay engaged and the later, more specific questions get real attention instead of leftover energy. That staged structure matters more than the specific format. The point is to leave a discovery session with a documented set of goals, risks, and open questions, not just a vibe.

## The shape of a discovery process that survives real clients

### 1. Pre-call intake

Before the first real conversation, get the basics in writing: what platform they're on (or moving to), current tech stack and app dependencies, budget range, hard deadlines, and who the actual decision-maker is. This is not a formal document; a short form or an email thread is enough. What it does is stop you from spending a discovery session establishing facts you could have gathered in five minutes, so the session itself can focus on the ambiguous parts.

### 2. The discovery session itself

Run it in stages rather than as an unstructured chat: outcome first (what does success look like, in the client's words), constraints second (platform, budget, timeline, existing systems), then the details that turn a goal into a build (which pages, which integrations, which edge cases). For anything beyond a small project, split this across two shorter sessions instead of one marathon call. Complex builds, multi-market storefronts, or projects with several stakeholders in the room justify a longer discovery window; industry guidance on Shopify discovery phases generally puts that window at two to four weeks depending on store complexity and the number of integrations involved. A simple storefront refresh does not need that runway, and forcing it through the same process wastes everyone's time.

### 3. A living brief, not a static document

The mistake most agencies make here is treating the discovery document as done once it's written. Real projects don't stay still. A client mentions a new requirement on a Slack thread three weeks in, or a stakeholder who wasn't in the original discovery call joins a later meeting with a different priority. If your discovery output is a PDF nobody reopens, that information either gets lost or gets bolted onto the project as an unplanned change order. Treat discovery as a model you keep updating, not a document you file away.

### 4. Turning findings into tickets

Once the outcome, constraints, and major unknowns are documented, the discovery output needs to become something a developer can build from: sequenced tickets with acceptance criteria, not a narrative summary. This is the step where a lot of discovery work quietly dies. The senior person who ran the sessions is now the bottleneck for translating notes into structured requirements, and that translation step is exactly where hours disappear before a developer ever touches the project.

### 5. Knowing when discovery is done enough

Discovery doesn't need to answer every question before development starts. It needs to answer enough of the questions that determine cost and architecture. A checklist test agencies commonly use: can you name the platform, the core pages or flows in scope, the integrations, and the client's definition of done? If yes, you likely have enough to quote and sequence a first sprint, and you can resolve the remaining open questions as you go rather than delaying the whole project for them.

## Common failure modes worth watching for

- **Discovery happens once and gets treated as permanent.** New information that arrives after kickoff has nowhere to go, so it turns into scope creep instead of an update to the plan.
- **Findings live in call notes nobody reopens.** If the only record of a decision is a transcript from week one, it might as well not exist by week six.
- **The quote goes out before the technical assessment.** Committing to a price before checking the client's current theme, apps, and data means the estimate is a guess wearing a number.
- **No one owns keeping the model current.** Discovery works when someone (or something) is responsible for folding new input back into the plan. Without that owner, the plan drifts from reality quietly.

## Where this gets easier to sustain

The hard part of client discovery for Shopify projects was never asking good questions once. It's keeping the picture current across every call, Slack message, and email for the life of a project, and doing it consistently across every client your agency runs at the same time. That's the part that breaks down as an agency grows past a handful of active projects: the senior person who used to sit in every discovery call can't be in six calls at once.

CommerceCopilot's Business Analyst agent is built around treating discovery as continuous rather than a one-time phase. It listens to the places requirements actually form (notes, connected Slack channels, meeting transcripts) and maintains a living model of the project: the outcome, what's confirmed, what's assumed, and what's still an open question. When something is unclear, it raises the question instead of guessing at an answer, which is the same discipline a good discovery process demands from a human team, just applied every time new information comes in rather than only in the kickoff call. The [discovery project guide](/docs/your-first-discovery-project) walks through setting one up, including how it turns accepted findings into sequenced, dev-ready tickets.

If your agency is earlier in evaluating where AI fits into delivery rather than just discovery, the [practical guide to getting started](/blog/ai-for-shopify-agency-how-to-get-started) covers how to pick a first project and what to measure, and [our overview of AI for Shopify agencies](/blog/what-is-ai-for-shopify-agencies) covers how the discovery role fits alongside the project management, technical, and QA work that follows it.

## A checklist for your next discovery process

- Collect platform, stack, budget range, and deadline before the first call, not during it.
- Structure sessions from outcome, to constraints, to specifics, and split complex projects across more than one session.
- Document findings as a model you keep updating, not a report you file away.
- Translate accepted findings into sequenced tickets with acceptance criteria before quoting.
- Assign someone (or something) to own keeping the model current after kickoff.
- Quote once you can name the platform, the core scope, the integrations, and the client's definition of done, not before.

## FAQ

### How long should Shopify project discovery take?

It depends on complexity. A straightforward storefront update might need a single structured session. Larger builds, especially with multiple integrations or several stakeholders, commonly run two to four weeks of discovery before a firm quote goes out. The goal is matching the depth of discovery to the complexity of the build, not applying the same process to every project regardless of size.

### Who should run client discovery: an account manager, a developer, or both?

Both, at different points. Someone comfortable asking business questions (goals, budget, decision-makers) should lead the early conversations, and a technical voice needs to weigh in before the quote goes out, to catch platform and integration constraints the business conversation won't surface on its own. Running discovery with only one perspective in the room is a common source of the estimates that go wrong later.

### What's the difference between discovery and scoping?

Discovery is the process of finding out what the client actually needs, including the parts they haven't articulated yet. Scoping is what happens after: turning that understanding into a defined set of deliverables, a timeline, and a price. Good scoping is only as accurate as the discovery underneath it, which is why rushing discovery to get to a quote faster usually costs more time later in revisions and change orders.

---
Canonical page: https://www.commercecopilot.ai/blog/shopify-agency-client-discovery-process