When a Shopify merchant says "we want to get into dynamic pricing," nine times out of ten they mean something far simpler than what they are about to be sold.
What they mean is: I want to react when a competitor cuts their price, and I don't want to find out about it two weeks late. Or: I want the prices in my store to follow some kind of logic, rather than whatever someone typed in eighteen months ago.
Both are entirely reasonable goals. The usual path to them runs through a repricing platform demo, a slide about price elasticity, and a rollout covering the entire catalogue which gets switched off three months later because nobody trusts its decisions.
This piece is about a shorter path. And it starts with one assumption worth stating up front: you don't begin with the whole store. You begin with a few dozen products.
What dynamic pricing isn't — in the context of a Shopify store
Our mental picture of dynamic pricing was shaped by three industries, none of which resembles the average e-commerce business: airlines, ride-hailing, and the large marketplaces. All three change prices in response to real-time demand, at enormous scale, using models nobody can read.
A Shopify store with eight hundred variants doesn't operate under those conditions and doesn't need those tools. There is no hour-by-hour demand volatility. There is no transaction volume sufficient to train elasticity models. What there is and what those industries lack is a finite, countable set of rules that can be written down as sentences.
For a store like that, dynamic pricing in practice means that prices follow from rules; the rules account for cost, margin, and the market; and recalculation happens on a schedule rather than at random. Once a week is plenty for most categories. That is already dynamic pricing. It just isn't the dynamic pricing from the sales deck.
Start with a few dozen products, not the catalogue
This is the most important sentence in the article, so let me unpack it properly.
The common mistake when moving into price automation is setting the scope to "everything." It feels natural if we're building a tool; surely it should cover the whole store. In practice, this is precisely the moment a project starts to die, for three independent reasons.
Reason one: the preparatory work scales linearly. In a moment I'll describe three things you need before switching anything on. All three are manual work done per variant. For sixty products, that's an afternoon. For two thousand, it's a quarter when enthusiasm fades, and priorities shift.
Reason two: trust is built on a small sample. Your commercial team will accept price automation only after it has made sensible decisions for a few weeks. Sixty proposals are reviewable; two thousand are not, and without that review, nobody clicks "approve" anyway.
Reason three: a mistake on a small scope is cheap. A badly worded rule across sixty products is one bad week in one category. The same rule across the full catalogue is a conversation nobody wants to have.
Which products to put in the pilot
A sensible starting scope is thirty to a hundred variants. Selection criteria:
- Real margin contribution. Take products from the top of your contribution ranking, not the ones that sell once a quarter. Automating long-tail pricing never pays for itself.
- Price comparability. Pick a category where the customer genuinely checks three stores before buying. That's where a market-based rule means something. For own-brand or niche products, there's nothing to compare against, so the rule collapses back to margin anyway.
- Reliable unit cost. A hard requirement. If you don't know a product's cost to the cent, keep it out of the pilot.
- Stability. Exclude bundles, anything currently on promotion, products covered by a supplier minimum-price agreement, and new arrivals with no sales history.
A practical note: one category, not a slice across five. A pricing rule for a single category is short and defensible in a meeting. A cross-section forces exceptions, and exceptions are where overcomplication begins.
What six weeks will tell you
The pilot exists to answer three questions you probably can't answer today: whether your cost data is trustworthy, whether the rules you invented produce prices you're willing to stand behind, and whether changing prices in that category moved sales at all. The third is the most interesting; sometimes the answer is no, and that too is a result worth six weeks.
Three things you need — for the selected products, not the whole store
1. Unit cost for every variant. Not "roughly 40% of the price." A specific number, in the cost field in Shopify, per variant. Without it, every margin rule is guesswork. This sounds trivial, but it's the single most frequently skipped step in the entire process, and across sixty products, it's an afternoon's work.
2. A margin floor set deliberately, not derived from cost of goods. Your minimum margin must cover more than the purchase price: returns, payment fees and fulfilment the variable costs that never appear on the product card. A category with a 30% return rate needs a different floor from one at 3%, even at identical cost.
3. Segmentation by price sensitivity. Not every product plays the same game. Some are comparison-shopped; some are own-brand with no direct equivalent anywhere. Treating both with one rule is the simplest way to give away margin for no reason.
Notice how much narrowing the scope changes the character of this list. For the full catalogue it's a project. For one category it's an afternoon.
The maturity ladder
It helps to know which rung you're on. Most stores should stop at the second, and that isn't a failure.
Level 0 — legacy prices. Set at some point, updated when someone remembers. Actual margin unknown. Surprisingly common.
Level 1 — margin rules. Price follows from cost and a target margin per category, recalculated on a cycle. Competitors aren't in the picture yet. This step alone usually surfaces a dozen products being sold below viability.
Level 2 — margin-plus-market rules. Competitor price data enters for comparison-shopped categories. The rule reads: follow the market, but never below the floor. This is the sweet spot for the overwhelming majority of Shopify stores.
Level 3 — optimisation. Elasticity, testing, models. Requires transactional data volume that smaller stores simply don't have.
You climb this ladder on a selected set of products, not the whole catalogue at once. Being at Level 2 in one category and Level 0 in all others is a perfectly normal intermediate state, not an inconsistency to be fixed.
Overcomplication is trying to jump straight to Level 3, across the entire catalogue, without having passed through 1 and 2 anywhere.
Level 2 in practice, without a repricing platform
Until recently, reaching Level 2 meant either a subscription or an integration written by a developer. For the past few months, there has been a third option, and it happens to suit a small scope particularly well.
You need three things:
The Shopify connector in Claude. Shopify has published its own official connector, available in Claude's integrations directory, built by Shopify itself rather than by the community. Authorisation runs in three stages, and at each one you decide what level of access to grant.
The Claude add-in for Microsoft 365. Installed from Microsoft Marketplace, it adds a sidebar panel inside Excel. Available on every paid Claude plan; one install covers Excel, Word and PowerPoint.
A workbook with four tabs. Rules, Prices, Log, and an instructions sheet.
Important: the connector lives in Claude, not in Excel
This is worth stating precisely, because "Excel connected to Shopify" is misleading. Excel has no connection to Shopify. There are two separate channels, and both terminate at Claude: the connector links Claude to your store, and the Office add-in links Claude to the open workbook. Claude is the bridge data travels Shopify → Claude → cell.
The consequences are practical. Close the Claude panel, and you're left with an ordinary spreadsheet: no refresh button, no Power Query connection, no schedule. Every cycle requires a human to open the sidebar and type a sentence. For a sixty-product pilot, that's a feature, not a limitation; it's exactly how the trust-building phase should look. There's a bonus, too: the file contains no credentials whatsoever, so you can send it to a colleague without a second thought.
If you eventually need a genuine Excel-to-store connection with a token, a schedule and a refresh button, commercial add-ins do exist (Devart, CData). That's a different philosophy, though: there's nobody there to read rules written as sentences, so you're back to formulas.
What's absent from the list above: an API key, an access token, a server, a script, a developer account.
Rules written as sentences, not formulas
Here we return to the overcomplication question, because it applies not only to scope but to how the rules are written.
A conventional pricing rule in a spreadsheet looks like this:
=IF(J7="IGNORE",F7,IF(AND(J7="COMPETITOR",I7<>""),MAX(N7,P7),MAX(N7,O7)))
It works. It's deterministic. And it's completely unreadable to the commercial director who came up with the rule in the first place. A pricing engine made of forty formulas like that, understood by one person in the company, is the overcomplication — whether it lives in Excel or in a platform costing a thousand euros a month.
The same rule in a sheet that Claude reads:
Be 2% cheaper than the lowest competitor. If a competitor is more expensive than us, raise our price to their level minus 2%. Never go below 35% margin.
That isn't a comment describing a formula. That is the rule that gets executed.
Pricing strategy stops being a technical artefact and becomes a document. You can read it aloud in a meeting. You can challenge it. You can change it without asking an analyst for a spare half hour. And if the rules can be read aloud and still make sense, that's the best available test of whether you've overcomplicated things.
The working loop: four sentences
Open the Claude panel in Excel, enable the Shopify connector, and type:
1. Pull the variants in the "Pricing pilot" collection from Shopify into the Prices sheet.
2. Read the Rules sheet and fill in the Proposed price column. In the Rationale column, write one sentence explaining why.
3. Show me every proposal that changes a price by more than 10%.
4. Update Shopify for the rows where Approved = YES only.
Note the first instruction: we're pulling one collection, not the whole catalogue. Creating a working collection in Shopify for the pilot is the simplest way to keep scope contained and to expand it later, deliberately, one category at a time.
Between steps three and four sits a human making a decision. That's the only point where one is essential and the only thing you shouldn't automate at the start.
The column that decides whether anyone trusts this
"Rationale." Claude writes there, in plain English, why it proposed a given price:
Accessories category — rule prohibits changes
The third row is the important one. A market rule and a margin rule came into conflict; margin won, and the tool said so. This is precisely where most repricing rollouts lose the team's trust; they show a number without an explanation.
At sixty rows, reading every rationale takes ten minutes. That makes it a real control mechanism rather than a theoretical one. At two thousand rows, nobody reads them, which is one more argument for starting small.
Safeguards you cannot skip
The approval column is mandatory. Everything defaults to NO. Nothing reaches the store without a human decision.
Export a product CSV before the first write. Shopify has no undo for bulk operations. That backup is your only route back.
Cap the batch size. Have it run in batches of 25 variants and report after each batch. Shopify rate-limits by query cost, and API arrays accept a maximum of 250 items.
Handle competitor data carefully. It's the only content in the workbook that comes from outside. Pasting raw text scraped from competitor sites also pastes potential instructions to the model, prompt injection. Keep SKUs, numbers and store names there, nothing else.
Authorisation is one-way. You can widen a connector's permission scope, but you can't narrow it without uninstalling the app. Grant the minimum on first connection.
Liability sits with the merchant. Shopify states this plainly: if a connected AI tool makes an incorrect change, the store is responsible.
When to widen the scope, and when to change tools
After a few cycles in which every proposal looked sensible, add another category. Then another. Expand by category rather than by individual product, because rules are defined at category level; adding one-off products creates exceptions.
Three signals that you've outgrown the tool itself:
Recalculation starts to drag. Above roughly a thousand variants, this gets slow. The right move then is to have Claude write an actual sync script. Excel becomes the interface, and the logic moves into code.
You need reproducibility to the cent. Claude arrives at prices by reasoning rather than by executing a formula; across many rows, two runs can differ slightly. There's a middle path: ask it to write the formula implementing the rule instead of typing the numbers. You still never write a formula yourself, but the sheet recalculates deterministically.
You need a hard audit trail. The Log sheet is a stand-in, not a substitute for an audit system.
One thing not to automate
The EU Omnibus Directive. Every price reduction must display the lowest price from the thirty days preceding the promotion in Shopify; that's the compareAtPrice field.
That's why the global rules in my workbook contain a single sentence: never change compareAtPrice. Automating the selling price is one thing. Automating the promotional claim is territory where a mistake costs more than the margin it was meant to save. (Merchants outside the EU should check their own local rules on reference and strike-through pricing; the principle travels even when the specific directive doesn't.)
In summary
Getting into dynamic pricing on Shopify doesn't start with choosing a tool, nor with covering the whole catalogue. It starts with picking a few dozen products whose cost you actually know, and writing a handful of rules for them that can be read aloud.
Start that way, and you'll have a result in six weeks and a basis for expansion. Start by rolling out a platform across two thousand SKUs, and you'll have a quarter of the cost of data collection and a switched-off tool by month five.
A rule you can't say out loud in one sentence usually isn't a strategy. It's a habit that happens to live in a cell.
Resources
To install
- The Claude Office add-in — in Excel: Insert → Get Add-ins → "Claude by Anthropic". Alternatively, the "Claude for Microsoft 365 (Excel, PowerPoint, and Word)" listing on Microsoft Marketplace
- Add-in overview page: claude.com/claude-for-microsoft-365
- Shopify connector (nothing to download — you authorise it in Claude's settings): claude.com/connectors/shopify
Anthropic documentation
- Claude for Excel — guide: support.claude.com/en/articles/12650343-use-claude-for-excel
- Connectors and Skills in the Office add-ins: claude.com/docs/office-agents/connectors-and-skills
- General availability announcement: claude.com/blog/collaborate-with-claude-across-excel-powerpoint-word-and-outlook
Shopify documentation
- Connecting AI tools, permissions and responsibility: help.shopify.com/en/manual/apps/connecting-ai-tools
- API rate limits: shopify.dev/docs/api/usage/limits
- Bulk variant price updates: shopify.dev/docs/api/admin-graphql/latest/mutations/productVariantsBulkUpdate
Alternative — true Excel ↔ Shopify connectors (paid)
- Devart Excel Add-in for Shopify, with write-back: devart.com/excel-addins/shopify/
- CData Excel Add-In: cdata.com/drivers/shopify/excel/
- ODBC driver and Power Query setup: docs.devart.com/odbc/shopify/excel.htm
- Supermetrics, read-only for reporting: supermetrics.com/connect/shopify-to-excel
