What Is a Discovery Conversation and Why It Should Come Before the Apparel ERP Demo

A founder on a Tuesday call wants to see the order screen. Her ops lead wants to see how a Shopify return posts back to available-to-sell. Her finance controller wants to see how a Nordstrom chargeback ties to the original ASN. The vendor on the other end opens a sandbox tenant seeded with demo data for a single-channel DTC brand and walks through a clean order from cart to ship. Forty minutes in, nobody on the buyer side has seen their actual problem on screen. They will still book a second call. They will still compare it to two other demos that did the same thing. And in six weeks they will pick the wrong system.

What is an apparel ERP discovery conversation?

An apparel ERP discovery conversation is a structured working session, usually 45 to 75 minutes, between a vendor’s solutions team and the brand’s operators, in which the vendor maps how the brand’s product data, production, inventory, orders, warehouse handoffs, payments, and reporting actually move today. It is not a sales qualification call. It is not a needs analysis form. It is a diagnostic that produces a written picture of the current state, the friction points, and the order in which those friction points need to be solved.

The output is a shared document, not a proposal. It names the systems in play (Shopify, NetSuite, a 3PL WMS, a wholesale portal, the spreadsheet that quietly runs allocation), the team members touching each handoff, and the workflows where data is re-keyed, reconciled, or guessed at. That document is what the demo is then built against. Without it, every demo is a generic product tour.

Why does this conversation have to come before the demo?

Because a demo shown against a guessed workflow misleads both sides. The vendor shows what is easy to show. The buyer evaluates against what they can see, not what they need. Six weeks later, in week two of implementation, the workflows nobody discussed surface and the project schedule slips.

When I am sitting across from a buyer comparing vendors, the pattern I see most often is that the buyer has watched three demos, taken three sets of notes, and is now trying to compare features in a spreadsheet. The features look roughly similar. The pricing looks roughly similar. The buyer picks on intuition, or on the salesperson they liked, or on the logo wall. None of those criteria predict whether the system will hold up when a real wholesale season hits in month four.

The discovery conversation is the only mechanism that produces real comparison criteria. It forces the buyer to articulate the workflow, and it forces the vendor to commit to whether their product handles that workflow as configured or as customized. Demos cannot do this. Demos are theater.

What does a real discovery conversation cover?

There are seven areas worth working through, and they map almost one-to-one onto the operational surface area of an apparel brand.

First, product data. How does a new style get from a tech pack into the system? Who keys the size run, the color codes, the cost, the HTS code, the barcode? Is there a PLM upstream or does product data start its life in a spreadsheet that gets imported? How many fields have to be right before a PO can be issued?

Second, production and supply. How are POs cut to vendors? How is WIP tracked? When a factory ships 920 units against a 1000 unit PO, where does that variance show up and who reconciles it? When the goods land at the 3PL, how does receipt post against the open PO?

Third, inventory. This is where most brands lose the plot. How many places does inventory live? What is the source of truth? When the 3PL counts on a Friday and finds 47 units missing, what happens on Monday morning in Shopify and in the wholesale system? For the $15M brand we see most often, this reconciliation costs 6 to 9 hours per week of one person’s time and produces a 2 to 3 percent oversell rate at peak. That number alone is usually enough to justify the conversation.

Fourth, orders. Wholesale orders, DTC orders, B2B portal orders, EDI orders from majors, marketplace orders. How are they captured, how are they allocated, how are they prioritized when stock is short? Who decides whether a Nordstrom PO ships complete or as partials?

Fifth, warehouse and 3PL. How do orders get to the warehouse? How does the warehouse confirm pick, pack, and ship? How does the ASN get generated and is it sent within the retailer’s required window? When the 3PL ships, how does fulfillment post back, and how quickly?

Sixth, payments and finance. How do invoices get generated? How does cash application work against wholesale invoices? How do chargebacks get coded and disputed?

Seventh, reporting. This is breakpoint 6 of the 6 Breakpoints framework, and it is the one that is usually invisible until you ask. What reports does the CEO ask for that take a person two days to assemble? What numbers does the team disagree about in Monday meetings? When the CFO and the ops lead bring different inventory numbers to a board meeting, which one is right and how do you know?

A discovery conversation that does not cover all seven is incomplete. You can move quickly through the areas that are stable and spend more time in the areas that are broken, but you cannot skip them.

How is this different from a sales qualification call?

A sales qualification call is for the vendor. It establishes budget, authority, need, and timeline so the vendor can decide whether to spend more time on the deal. It usually takes 20 to 30 minutes. The output is a notes field in a CRM.

A discovery conversation is for the buyer. It establishes whether the brand’s actual operational shape fits the system being considered. The output is a written current-state document the buyer keeps. If a vendor’s discovery process produces nothing the buyer can take away, it was qualification dressed up in different language.

The distinction matters because vendors who skip discovery and go straight to demo are usually selling a horizontal product that does not have an apparel-specific opinion. They cannot diagnose because they do not know what to ask. Generic ERPs do this. Point tools do this. The result is that the buyer spends nine months in implementation discovering the constraints that a 60 minute conversation would have surfaced.

What should a buyer expect to be asked?

Real discovery questions are specific and they are uncomfortable. Some examples of the right shape:

• How long does it take, in business days, for a customer return to post back to available-to-sell on the website?
• When you run a flash sale or a drop, what is the gap between when the front end shows sold-out and when the 3PL actually has zero units?
• What percentage of your wholesale invoices get short-paid, and how many of those short-pays do you successfully dispute?
• When a retailer issues a chargeback for a late ASN, who finds out about it, and how long after the violation?
• How many SKUs are active right now, and how many of those have a complete record including barcode, HTS, country of origin, and cost?
• When you cut a PO to a factory, how many systems get updated, and by whom?

If the questions sound like they come from someone who has run an apparel ops team, they probably do. If they sound like a generic SaaS qualification script, the vendor is not equipped to help.

When does skipping discovery actually break the project?

The objections I hear most often in evaluations are about timeline. The buyer wants to move fast. They have already lost a quarter to the evaluation. They want to see the product, get a price, and sign. Discovery feels like a delay.

It is not. Skipping discovery is the single biggest predictor of an implementation that overruns by two to three months. Here is the mechanism. The buyer picks a system on demo impressions. The vendor scopes the implementation against a thin statement of need. Configuration starts. In week three, the wholesale team mentions they actually ship 40 percent of their orders as drop-ship from the factory directly to the retailer, never touching the 3PL. The configuration assumed everything went through the warehouse. Re-scope. Week six, finance mentions they need landed cost to include duty, freight, and a brokerage fee allocated per unit, and the current configuration only handles a single landed cost number. Re-scope. Week nine, the CEO sees the first reporting build and says none of these reports match what she actually looks at every Monday. Re-scope.

Each re-scope is a workflow that a one hour discovery would have surfaced. The cost of the delay, paid in extended dual-running, in consultant hours, in the operations team’s morale, dwarfs the cost of the discovery conversation by an order of magnitude.

What does good discovery output look like?

A written current-state map. It does not need to be long. Six to ten pages is plenty. It should contain a systems diagram showing every place data lives today and how it flows between them. It should contain a table of the workflows reviewed, the friction in each, and a rough estimate of the time or money cost. It should contain a prioritized list of which breakpoints are active right now and which are coming in the next 12 months. It should contain a clear statement of which of the 6 Breakpoints the brand is actively living in.

For a brand in the $10M to $20M predictable breakpoint zone, this document usually reveals that they are replacing three to five tools plus spreadsheets, that breakpoints 3 (inventory truth) and 5 (warehouse execution) are the active fires, and that breakpoint 6 (reporting) is the one the CEO is loudest about even though it is downstream of the other two. Knowing that order of operations changes how the implementation is sequenced.

This document is also what makes vendor comparison real. Two vendors handed the same current-state map will produce two different recommendations. The differences are the buying decision.

Why do most vendors skip this step?

Three reasons. First, it is expensive. A solutions person spending 75 minutes on discovery plus three or four hours writing up the current-state map is a real cost per opportunity. Vendors selling on volume cannot afford it. Vendors selling on fit can.

Second, it requires apparel-specific expertise. A discovery conversation about ASN compliance, drop-ship to retailer, allocation against wholesale-committed pools, and channel-aware ATS cannot be run by a generalist. The vendor needs people who have lived in the workflows. If the discovery call gets handed to a junior SDR working off a script, the buyer has learned everything they need to know about that vendor’s depth.

Third, discovery surfaces fit problems early. A vendor whose product does not handle multi-entity wholesale, or does not handle a B2B portal with brand-specific catalogs, would rather find that out in month two of implementation than in hour one of discovery. The buyer’s interest is exactly the opposite.

The shape of the right POV here: a buyer should refuse to watch a demo until a discovery conversation has happened, and should refuse to sign until the demo has been rebuilt against the current-state map. If a vendor will not do that work, they are telling the buyer something important about how the implementation is going to go.

What this means for an apparel operations team

The discovery conversation is the cheapest insurance an apparel brand can buy during a system evaluation. It costs one to two hours of the operations team’s time per vendor. It produces a written artifact the brand keeps regardless of which vendor is chosen. It surfaces the real cost of the status quo in numbers the team can take to the board.

For an ops lead running an evaluation, the practical move is to insist on discovery before any demo, and to require the written current-state map as the output. Any vendor that will not do this is selling on demo polish, not on fit. That is a useful filter on its own.

For a CFO signing the check, the discovery document is the document that justifies the spend. It contains the hours per week being lost to reconciliation, the oversell rate at peak, the chargeback exposure, and the FTE cost of data plumbing. Those numbers are what the investment is being made against. Without them, the business case is a feature list, and feature lists do not survive contact with a board.