How I Approach Ecommerce Discovery Calls

After twelve years in ecommerce and several years as an independent consultant, I've done hundreds of discovery calls. The format has evolved, but the principles haven't changed: listen more than you talk, ask questions that reveal the real problem, and be honest about whether you can help.

Here's how I approach these conversations.

Before the call

I do fifteen to twenty minutes of preparation. I look at their current website — the frontend, the checkout flow, the site speed, the technology stack (BuiltWith or Wappalyzer tells you most of what you need). I look at their LinkedIn to understand the team structure. If they've mentioned specific problems in their initial email, I think about likely causes and possible approaches.

This isn't deep research. It's enough to ask informed questions and avoid wasting the first ten minutes on things I could have learned beforehand.

The first question

I always start with the same question: "What's prompted this conversation now?"

Not "what do you need?" or "what are your requirements?" Those questions get you a feature list. I want to understand the trigger. Something changed. A platform became too expensive. Performance degraded. A key person left. The business outgrew its tools. A board member asked a question nobody could answer.

The trigger tells you the urgency, the emotional context, and often the real problem underneath the stated one. A brand that says "we need to replatform" is often actually saying "we've lost confidence in our current setup and don't know how to fix it." Those are different problems with different solutions.

Understanding the business

Before talking technology, I need to understand the business. Revenue and order volume give me a sense of scale. Number of SKUs and catalogue complexity tell me about data management needs. Number of markets and currencies tell me about operational complexity.

I ask about their team. Who manages the website day-to-day? Who handles technical decisions? Is there an in-house developer or is everything outsourced? This tells me what kind of solution they can actually operate. There's no point recommending an architecture that requires a three-person engineering team if they have a marketing manager and a freelance designer.

I ask about their current pain points — not in abstract, but specifically. "What takes longer than it should?" and "What broke recently?" get better answers than "what are your challenges?"

The technical conversation

Once I understand the business context, I ask about technology. What platform are they on? What integrations exist? What third-party tools are they using? What do they wish worked differently?

I'm listening for patterns: how much of their technology spend goes to maintenance versus new capability? Are they fighting their platform or working with it? Do they have visibility into how their systems perform, or do they find out about problems when customers complain? These are the same signals I describe in what I look for in a good ecommerce tech stack.

If they're on Magento, I ask about their hosting setup, their deployment process, and their extension dependency — often the conversation turns to migration planning. If they're on Shopify, I ask about their app stack and integration architecture. The answers tell me whether the problem is the platform, the implementation, or the process around it.

What I won't do on a discovery call

I won't give a price. I can give a range, but meaningful pricing requires understanding the scope, and that takes more than a thirty-minute conversation. Brands that need a price on the first call are usually shopping for the lowest number, and that's not a good basis for a working relationship.

I won't agree that their proposed solution is the right one before I've understood the problem. If someone calls saying "we need a headless rebuild," I'll explore why they think that before agreeing. Often the underlying problem has a simpler solution.

I won't pretend I can do something I can't. If the project needs capabilities outside my experience — native mobile development, heavy design work, Salesforce integration — I'll say so. Honesty on the first call saves everyone time.

Ending the call

I finish every discovery call with three things: a summary of what I heard (to confirm I understood correctly), an honest assessment of whether I think I can help, and a clear next step.

The next step is usually a scoping document or a paid discovery session if the project is complex enough to warrant it. Sometimes the next step is "I don't think you need me — here's what I'd suggest you do instead." That happens more than you'd expect, and it's always the right call. A referral or honest advice builds more trust than a forced engagement.

The discovery call isn't a sales pitch. It's a diagnostic conversation. Both sides are figuring out whether there's a good fit. The best client relationships I have started with discovery calls where I was genuinely curious about their business, not trying to close a deal.