Ecommerce Questions to Ask Client
Discovery questions for an agency, freelancer, or in-house team scoping an online store build or replatform. They cover how the shop runs today, the commercial numbers behind it, integrations, budget and dates, and who keeps the thing running after launch.
The questions
Open any question for the note
Walk me through how someone finds you and buys something today.
Why ask it
Narrating the current path surfaces steps they have stopped noticing: a spreadsheet export, an order taken by phone, a discount typed in by hand. If they cannot describe it end to end, nobody on their side owns the funnel, and that will shape who you need in the room.
What platform are you on now, and what made you start looking at alternatives?
Why ask it
The trigger matters more than the platform name. A failed integration, a plugin that broke at checkout, or a bad relationship with the last developer each point at a different project. Beware of an answer that is only about the software being old.
What has to be different a year from now for you to call this a success?
Why ask it
You are listening for one or two outcomes, not a feature list. Vague answers about being modern or user friendly mean the success criteria will be invented later, usually by whoever is unhappiest at launch.
Roughly what are you doing in monthly revenue and order volume, and where do you expect that to be next year?
Why ask it
Order volume decides architecture, hosting, and whether manual fulfilment survives the year. Reluctance to share it usually signals either much smaller numbers than implied or that the person in the meeting cannot see the figures.
Who actually buys from you, and how do you know?
Why ask it
The second half separates evidence from assumption. Answers grounded in order data, returns, or support tickets are worth designing around. A described persona with no source behind it is a guess you would be inheriting.
What breaks most often, or takes the most manual work, in running the store now?
Why ask it
Daily friction is where you can produce visible value early, and it is usually invisible in a brief. Whoever does that manual work should be interviewed directly, because managers routinely underestimate how many hours it costs.
What other systems does the store need to talk to, and who maintains them?
Why ask it
Ownership of each system predicts your schedule more than the integration itself does. An accounting system maintained by an external bookkeeper who answers weekly can hold up a launch that is otherwise ready.
What number did you have in mind for this project, and does it cover the first year of running it?
Why ask it
Splitting build from run stops the common failure where the budget is spent on launch and nothing remains for hosting, apps, or fixes. If they refuse any range at all, expect to price against an invisible competing quote.
Is there a date this has to be live by, and what happens if it slips?
Why ask it
A date tied to a trade show, a contract ending, or a seasonal peak is real. A date with no consequence attached is a preference, and treating the two the same is how teams end up cutting testing for no reason.
Who signs off on the design, and who can stop the project?
Why ask it
These are often different people, and the second one may not be in the meeting. Finding the silent approver now avoids a rebuild after a founder or investor sees the work for the first time in week six.
If we could only ship half of what you have described, which half would it be?
Why ask it
Forcing a cut produces a genuine priority order, which asking for must-haves does not. If everything is required, the scope has not been thought through and the first hard deadline will make the decision for them.
How do you track stock today, and where does that data actually live?
Why ask it
Look for the real source of truth, which is often a spreadsheet or a warehouse system rather than the store. Building a site that assumes accurate stock levels on top of a manual count causes oversells in the first busy week.
Which payment methods and currencies do you need working on day one?
Why ask it
Local wallets, invoicing for trade customers, and buy-now-pay-later each carry their own setup and approval time. Payment provider onboarding is a common cause of launch slippage and it sits outside your control.
How much of your traffic comes from search, and are there URLs we cannot afford to break?
Why ask it
A store living on organic traffic needs a redirect map treated as a deliverable, not an afterthought. If they cannot answer, ask for analytics access before quoting, because the migration risk changes the price.
Who answers customer emails, and what do people write in about most?
Why ask it
Repeat support questions are a map of what the current site fails to explain: delivery times, sizing, returns. Fixing those on the page reduces support load, which is easier to demonstrate than a conversion claim.
What numbers do you look at each week, and where do you get them now?
Why ask it
This tells you what reporting has to exist on day one versus what merely sounds useful. If the answer is that someone builds a report by hand every Monday, you have found a quick win worth scoping.
Are there compliance or accessibility requirements we need to design around?
Why ask it
Card handling, EU or UK data rules, age restrictions, and public sector accessibility standards all constrain design and hosting. Discovering one of these after the build starts usually means reworking checkout, the least pleasant thing to rework.
What share of your orders come from phones, and how does the current mobile checkout hold up?
Why ask it
The gap between mobile traffic and mobile revenue is the most useful single number in this conversation, and most merchants have never looked at it. A wide gap justifies spending the budget on checkout rather than on the homepage.
When do you get your biggest spikes, and what happened last time the site was under load?
Why ask it
A specific story about a slow Black Friday or a sold-out launch tells you what to test against. No story at all usually means no monitoring, so add it to the scope rather than assuming they will notice problems.
After launch, who on your side runs this day to day, and what will they need to be shown?
Why ask it
Naming a person turns training into a plannable task. If nobody is named, the site will drift back to you for small edits, so either price that as support or teach whoever is closest to the work.
Running an ecommerce discovery conversation
Practical guidance for the conversation itself
Before the call
Shop the store first
Place a small real order if you can, or at least get to the payment step. Ten minutes of this replaces a lot of questions and lets you ask about specific things you saw rather than in general terms.
Ask for read access to analytics and the admin
Traffic sources, device split, and product counts change your estimate more than anything said out loud. If access is refused before contract, note it: you will be quoting on their description of the site rather than the site.
Find out who is in the meeting and who is not
Marketing, operations, and finance want different things from the same store. If only one of them is present, ask who else has to live with the result and get them into the second call.
During the conversation
- Ask for the last time something went wrong rather than for their process. Stories contain the detail that process descriptions leave out.
- When they name a feature, ask what it is for. Half the time the underlying need has a cheaper answer than the feature they requested.
- Write down their numbers in their words, including the ones they guess at, and mark which were guesses.
- Repeat scope back at the end of the call and let them correct you while it is still cheap to be wrong.
- Note anything that depends on a third party: payment approvals, ERP vendors, a photographer who owes them product images.
Answers that should slow you down
- No budget range at all, combined with a firm launch date. One of the two will have to give, and it will not be the date.
- The person describing the customer has never read a support ticket or a return reason.
- A previous agency was fired and nobody will say what for. Ask directly, and ask who owns the code and the domain.
- Stock levels live in a spreadsheet that one person updates, and that person is not part of the project.
- Every feature is described as needed for launch, with no ranking after you ask twice.
Turning the answers into a proposal
- Separate the build price from the running cost, and list the running items by name: hosting, apps, payment fees, support hours.
- Put the redirect map, payment provider onboarding, and content migration in the plan as their own tasks with owners, since these are the usual sources of delay.
- State the success measures they gave you, in their wording, so the launch is judged against them rather than against feelings.
- List assumptions you are pricing on, including order volume and the number of products, and say what happens if they turn out to be wrong.