A merchant writes a brief. The brief lists what they want done. The honest consultant reads the brief, scopes the work, sends a quote, ships the work. Everyone is satisfied. The merchant got what they asked for.
Then six months later, the merchant is still hitting the same problem. The work shipped. The spec was met. The thing they were actually trying to buy still hasn't arrived.
This happens because the literal ask in a brief almost never matches the spec the merchant would write if they had the words for it. They write the symptom they can see, not the operational shape they're trying to escape. If the consultant scopes off the literal ask, the result is technically what was agreed to and substantively the wrong thing.
Three patterns I've worked through recently — different store sizes, different stack pieces, same gap.
Pattern 1: "Integrate Shopify and Amazon"
An Australian Shopify merchant wrote with a clear brief. There was already a Shopify-to-Amazon connector installed; only a limited subset of their catalog was live on Amazon; they wanted to expand the catalog and make the integration work reliably. The literal ask was a connector configuration job.
Read the brief one more time. The line that mattered: "don't have the patience for Amazon Seller." Translation: they have logged into Seller Central, they have hit a wall, they have decided that wall is not their job to scale. What they were trying to buy wasn't a connector configuration. It was not having to live inside Seller Central. Reliable sync was part of that. Catalog expansion was part of that. Someone watching the connection so that when something breaks they're not the one finding out — that was the rest of it.
If I scope to the literal ask, I deliver a one-time configuration job. Three months later they're back in Seller Central watching listings get rejected for missing GTIN data. The brief was met. The actual product spec was not.
If I scope to the real spec, the shape of the engagement changes. One-time setup becomes setup-plus-monitoring. A flat quote becomes a base engagement plus a small ongoing retainer. The deliverable isn't "the connector works." The deliverable is "you don't have to think about this surface anymore." Those are different jobs at different prices and they both involve the same connector.
The literal ask describes the symptom the merchant can see. The real spec is the operational shape they're trying to escape.
Pattern 2: "Answer these five questions so I can build"
A US subscriptions brand, mid-stack rebuild, June launch deadline. Post-call follow-up time. I had a list of open questions for them that needed answering before I could ship: which add-on logic to use, which threshold to set on a particular flow, which upsell SKUs to pull, which content blocks to populate, which tag naming convention to commit to. Five questions, all reasonable, all things only the merchant can decide.
The literal ask back to me: answer these five questions so the build can proceed.
The real spec, if I sat with it for a minute: the merchant is hands-on, the brand has a strong voice, the founder trusts her own taste on the things her customers will see, but she does not want to answer five abstract scoping questions in a doc. She wants to see a draft and react to it. The five-questions ask is what the build needs; the founder's actual operating mode is "show me a working thing, I'll tell you what to change."
Reframe the reply. Don't send the five-question doc. Send a build that has sensible defaults on all five — each one exposed in the admin as an editable section setting. Tell the merchant: I picked a placeholder for each of these. Here's why I picked it. Swap any of them in two clicks from the admin. If you don't touch them, the build ships with the placeholders.
The merchant's role shifts from "answer questions in the abstract" to "react to a working demo." The five questions still get answered — they get answered by the merchant clicking around the live thing, not by an email round trip. The deadline gets protected because the build is no longer waiting on the merchant's reply cadence. The merchant gets to use the part of their brain that's actually good at this (taste and recognition) instead of the part that's bad at it (abstract specification).
Same project. Same scope. Different framing of who does what when. The literal ask would have produced a doc and a delay. The real spec produces a working draft and a faster ship.
Pattern 3: "Fix Meta Business Manager"
An apparel merchant just past launch. Cataloging on Facebook was broken — products approved on the back-end, the Business Manager dashboard showing green, none of it visible to anyone who actually clicked through to the Facebook Page or the Instagram profile. The literal ask: fix Meta Business Manager. Make the integration work.
What he was trying to buy wasn't a working Meta Business Manager. The Meta Business Manager was already showing all-green on the things it tracks. What he was trying to buy was customers seeing his shop when they land on his Facebook Page or his Instagram. Those two things are usually correlated but they are not the same thing, and his Business Manager being green while his Facebook Page being empty was the proof.
If I scope to the literal ask, I poke at Business Manager settings, re-link the Commerce account, file a Meta support ticket. Most of that work has already been done, twice, by the merchant. The pattern matches: when a merchant says "fix the dashboard," the dashboard is usually fine and the surface the customer actually sees is not.
The reframe: the deliverable is screenshots of the live shop visible on Facebook and Instagram from a customer's point of view, not a green Business Manager status panel. The work that produces those screenshots is different — it touches Page-level settings, Instagram shopping eligibility, the catalog feed configuration, occasionally a manual re-publish from a tab the dashboard doesn't surface. The validation is visual, on the customer surface, not on the operator surface.
Same word in the brief ("fix"). Different actual project. Different deliverable. Different way of knowing when you're done.
Three patterns, one discipline
The three reframes look unrelated. They're the same move:
- The Amazon connector ask reframes from "configure the integration" to "take a platform off the merchant's plate."
- The five-questions ask reframes from "answer abstract questions in a doc" to "react to a working draft in the admin."
- The Meta Business Manager ask reframes from "fix the dashboard" to "make the customer surface show what the dashboard claims is there."
Each one moves the deliverable from the surface the merchant can describe to the surface they're actually trying to change. Each one shifts the validation from "the spec is technically met" to "the operational shape you wanted has actually shown up." Each one changes the quote.
How to spot the reframe before you quote
Whether you're the merchant evaluating a quote or the consultant writing one, the diagnostic is the same. Look at the brief and ask:
- What's the symptom phrase? The line in the brief that reads as a complaint, not a request. "Don't have the patience for..." / "Can't keep up with..." / "Tired of having to...". The symptom phrase usually points at the real spec better than the request phrase does.
- If the literal ask shipped tomorrow, would the merchant be done worrying about this? If yes, the literal ask is the spec. If no — if there's a next thing the merchant would have to keep doing themselves — the real spec is the operational shape that removes the next thing.
- Where does the merchant want to stop looking? Connector settings? Admin dashboards? Status panels? The surfaces the merchant wants to stop having to check are usually the ones the brief is implicitly trying to make invisible.
- What's the validation that the work succeeded? If the validation is a green status on an operator surface, but the merchant's frustration is on a customer surface, the two won't line up. The validation has to live where the actual problem lives.
None of these are scope-creep questions. They're scope-accuracy questions. The reframe almost never produces a bigger quote than the literal ask — it usually produces a differently-shaped one. Sometimes smaller (because the actual problem is narrower than the merchant feared). Sometimes split into two pieces (because the literal ask and the real spec belong to two different time horizons). Sometimes a one-time job becomes a smaller one-time plus a tiny ongoing — which the merchant actually wanted but didn't have language for.
Why the gap is structural
Merchants describe their stores the way they look at them — through the admin, through the dashboards, through the surfaces vendors give them. Those surfaces are the language merchants have. When something hurts, the words for the hurt are the words on the screen they were last looking at. "Fix Meta Business Manager" is the language Meta gave the merchant. "Integrate Shopify and Amazon" is the language the Shopify App Store gave them. The literal ask is the dashboard talking through the merchant.
The real product spec lives one layer below — at the operational shape the merchant is trying to land in. That layer doesn't have a vendor screen attached to it, so it doesn't have ready-made words. The merchant has to be helped to it, usually by a consultant who asks two or three questions about what the merchant is trying to stop doing rather than what they're trying to start doing.
The reframe is the work
Most of the value in a good Shopify engagement is decided in the half-hour before the quote gets written. After the quote is signed, the work is mostly competence. Before the quote is signed, the work is reading the brief past its literal surface — and saying back to the merchant what they're actually asking for, in language they recognize once it's said out loud.
If you're a merchant about to send a Shopify brief: write the literal ask, then add a paragraph at the bottom describing what you'd want to stop having to do once the work shipped. That paragraph is the real spec. Send both. If the consultant only quotes the first paragraph, you'll know who you're working with.
If you're a consultant about to send a quote: re-read the brief one more time and find the symptom phrase. Reply with the reframe before the price. The merchant who needs the reframe will thank you. The merchant who really did just want the literal thing will tell you so, and now you both have the same understanding before any money moves.
If you've got a brief in front of you right now and the quote you've been imagining feels slightly wrong-shaped, the reframe is usually why. Grab a slot and we can pull it apart in fifteen minutes.