A Shopify AI project should not start by plugging in a chatbot. It should start with a business problem the team can verify: a known input, a defined output, a named owner, and a way to roll the change back. Typical first use cases include cleaning product data, routing support questions, localizing market content, or flagging inventory exceptions. Only after that use case is clear should the team decide whether to use Shopify’s built-in AI tools, an app, a custom app, or an external model.
The useful aim is narrower than “make the store intelligent”. It is to shorten repetitive human work while keeping decisions about orders, prices, inventory and compliance traceable. A slogan of store-wide automation is less useful than a pilot the team can accept, pause or reject on evidence.
Ninety days is a planning cadence, not a result
Ninety days is a review-friendly planning window for one market and one use case. It is not a delivery date, a staffing plan, or a promise of revenue, conversion, rankings, citations, cost savings or safety. A store may stay in definition or offline testing because permissions, data quality, market-policy review, human review capacity or a failed sample need more work. Reaching day 90 does not authorize expansion.
The decision at the end of the window is still a decision. Valid outcomes include a limited live trial, a narrower scope, a pause, or a return to the last stable process. Automatic scale across markets and workflows is not one of them.
Choose one use case before choosing a tool
A good first use case has four properties: the input can be named, the output can be checked, a person owns the stop decision, and a wrong result can be reversed without rewriting the live catalog or the checkout. “Cross-border growth” is not a use case. “Draft English short descriptions for one product family in one market, from approved fields, with a merchandiser as the publisher” is a use case.
Illustrative starting points, not a required portfolio:
- Product data cleanup: turn titles, attributes, units and restricted terms into a field dictionary, then let a model draft descriptions from those fields. Field dictionaries and market difference tables are covered separately in product data governance.
- Support routing: classify a question, quote an approved knowledge entry, or place the customer in a human queue. For knowledge bases, risk routing and takeover, see AI customer support.
- Market content: rewrite an approved source for one language and one market, without inventing a second specification set.
- Inventory or operations alerts: summarize an exception from store records and send it to a person. The model does not change available quantity, price or a purchase order.
Then choose the tool against that boundary. Shopify AI-powered tools describe built-in assistants and connections to third-party AI platforms; the merchant still controls what each tool can access and do. A custom app that reads or writes store data should use the current Admin API with the smallest permission set that the use case requires. An external model is another processing step, not a second system of record.
Name owners before the calendar starts
Collaboration here is not a shared chat thread. It is a short ownership map so a draft cannot be published by whoever happens to be online. One person may hold two roles in a small team; “the team owns it” is not a stop condition.
- Program owner: keeps the use case, market, calendar and go/no-go decision in one place. Does not replace a market, privacy or merchandising review.
- Merchandising or content owner: approves visible copy, product claims and what may be said about a SKU.
- Data and privacy owner: decides which fields may enter a model, which must be redacted, how long logs are kept, and who can see them.
- Market or operations owner: checks language, currency, shipping, returns and restricted-product rules against the live store, not against model memory.
- Engineering owner: permissions, keys, retries, idempotency, logging and a path that still works when the model is unavailable.
- Support lead: only if the use case is support; owns banned phrases, escalation and whether an answer may leave the knowledge base.
Each use case also needs a backup owner and a role that can freeze new scope without waiting for the next weekly meeting. Which store tasks may be drafted, and which decisions stay human, is a separate boundary discussion in AI and human teams.
Days 1–30: define the use case and the data boundary
The first month is definition, not launch. Build a field dictionary for the objects the use case will touch — typically products, orders, customers and markets. Mark each field as allowed into the model, required to be redacted, or reserved for a human approval. If a field has no demonstrated purpose, permission or retention path, it stays out.
Write a one-page use case card before anyone generates copy. An illustrative card includes: the use case; the market and language; the input source and version; the allowed output states (draft, needs evidence, revise, approved, rejected); prohibited actions; the escalation path; the rollback condition; and the named owner. “Improve content with AI” is not a card.
Also record what must remain true if the model is down. Customers should still be able to browse, add to cart, check out, or reach a person. An assistant that cannot fail closed is not ready for a live trial.
This phase is complete when a reviewer who was not in the kickoff meeting can see the use case, the field list, the owner, the stop condition and the rollback pointer. If those items are missing, stay in definition. Do not treat week four on the calendar as the start of a pilot.
Days 31–60: evaluate offline
Prepare a test set on one market and one product family before any customer-facing traffic. Cover normal records, missing fields, conflicting fields, malicious or prompt-injection style input, and questions the store must refuse. The point is not to demonstrate fluency. It is to see whether the system quotes the source, marks gaps, or invents a complete-sounding answer.
Pass conditions belong to the business, not to an unsourced “99% accuracy” or “three times faster” claim. Examples a team can actually score:
- Does every product fact in the draft match the current store record or the approved field dictionary?
- Are missing values labelled as unknown, rather than filled from general knowledge?
- Does the system refuse price, inventory, refund, tax or payment conclusions it is not allowed to make?
- Can a second reviewer, using only the log, tell which source version was used?
Do not define failure handling as “regenerate until it sounds right”. Regeneration can hide a missing fact. Keep the failed output, record what was missing, send the item to a person, and decide whether the dictionary, the prompt boundary or the use case itself needs repair.
This phase is complete when the test set, pass conditions, refusal rules and sample logs exist, and the offline environment uses approved, minimised test data without permission to alter production records. A clean sample is not permission to publish.
Days 61–90: limited live traffic
If the offline bar is met, run a small live trial inside the same market and use case. Log each suggestion, human edit, refusal, escalation and the practical cost of a wrong output — extra tickets, a blocked publish, a restored version. The log supports the review decision. A screenshot of a fluent answer is not.
Expand scope only when quality, response time, operating cost and business risk all meet the team’s own thresholds. Those thresholds are internal. They are not a ranking, citation or sales forecast. If any threshold is missed, freeze new scope, keep the evidence, check whether the live store was affected, and return to the last approved baseline or to human handling.
Facts, permissions, approval and rollback for agent-style workflows are covered in more detail in AI agent workflows. This calendar only decides whether one use case has earned a wider audience.
| Phase | What to produce | Who owns it | Evidence that it happened |
|---|---|---|---|
| Define | Use case, market, field dictionary, prohibited actions, rollback | Program owner, with data and market owners | Use case card and field list a second reviewer can follow |
| Evaluate | Test set, pass conditions, refusal rules | Merchandising or support lead, with engineering | Scored samples, including missing-field and unanswerable cases |
| Pilot | Limited traffic, human review, cost of errors, anomaly log | Named operator and recorded approval responsibility | Suggestion, edit, refusal and escalation records |
| Expand or stop | Version, permissions, training, rollback drill | Program owner after the other roles sign off | Release checklist, or a recorded pause / rollback |
The table is a planning aid. Calendar progress is not automatic approval.
What the model may draft, and what the store must still own
Product descriptions, recommendations and support answers can be drafted by a model. Price, discounts, inventory, refund eligibility, tax and payment results must come from the store and the order system. If the current value is unavailable, mark it unknown or hand it to a person. Do not let model memory become a store fact.
Cross-border pilots have to keep language, currency, shipping, returns and restricted-product rules by market. Shopify Markets is the configuration to check against, not a substitute for a market owner. A linguistically correct paragraph can still apply the wrong returns window. Language chooses wording; the market chooses the rule.
Connections to the Admin API, order webhooks or a third-party system need a minimum permission set, key rotation, retries, idempotency and a human takeover path written down before the first live call. A suggestion that sounds like an order confirmation, a refund or a price change is still a suggestion. For this pilot, keep high-impact payment, refund, procurement, contract, credit and pricing decisions within the merchant’s approved human workflow. This is a recommended pilot boundary, not a claim that Shopify cannot automate authorised actions.
Example measures, not outcome promises
Measure the pilot as a control problem first. The figures below are examples a team can collect. They are not acceptance standards published by Shopify or Google, and they are not a forecast of conversion or traffic.
- Quality: share of drafts that needed a factual correction; unsupported claims caught before publish; correct refusals on out-of-scope or unanswerable input; agreement between the draft and the source fields.
- Operations: review hours; rework after a failed sample; time from a source-field change to an updated draft; whether a second reviewer can reconstruct the decision from the log.
- Risk: escalations; blocked actions that would have changed price, inventory, refund eligibility or a market policy; whether browse, cart, checkout and human transfer still work when the model is unavailable.
- Business observation: repeat contacts or tickets caused by conflicting product or policy text. Sales and conversion move for many reasons; do not write a short-term GMV change as an AI-project result.
Keep using Search Console for crawl, index and classic page performance. Search Console also currently includes a separate generative AI performance report for how site links appear in AI Overviews and AI Mode, with views by page, country or region, and device. An impression in that report is not a click, a citation the merchant controls, or a sale. Do not treat a rise in AI impressions as proof that the pilot worked, and do not treat a missing report as proof that the content failed.
Keep SEO and GEO in view, without making them the pilot
If the use case produces public content, write answers that state the conclusion, the scope, the evidence and the exceptions. That helps people, and it gives search and AI systems something they can check. It does not guarantee display or citation. Google’s guidance on AI features and your website is that established SEO still applies; there is no extra technical requirement and no dedicated GEO schema. Google’s generative-AI content guidance asks for accurate, people-first pages. Neither document replaces the merchant’s own fact review.
Fact cards, evidence, structured data that matches the visible page, and how SEO and GEO sit together are the subject of GEO content governance. If the pilot’s output cannot point to a current product record or policy, it is not ready to be reused anywhere — on the site, in search, or in an assistant.
When not to expand
Stop adding markets, SKUs, channels or write permissions when any of the following is true: there is no named owner; a claim has no current source; a permission or retention path is unclear; a market or policy statement disagrees with the live store; a draft is being read as a completed refund, price change or order; the model is unavailable and the storefront cannot complete a purchase or a human handoff; or the review queue is already backlogged.
The common sequence is: freeze new scope; keep the input, output, version and log; check whether the live store was affected; then repair, hand to a person, or roll back. Preserve the records needed to verify recovery, subject to the store’s privacy and retention rules. Calendar progress is not a reason to continue.
Common questions
What should a Shopify AI project do first?
Pick one use case with a clear boundary, a rollback path and a way to count the human work it is meant to reduce. Then build the field list, permissions and acceptance set. Choosing a model or an app before that usually produces fluent copy with no owner.
Can AI change prices or inventory?
Not by default in this plan. Price, inventory, refunds and tax need the current store record, permission control and human approval. A model may draft a description or summarize an exception. It should not become the system of record for a commercial fact.
Will 90 days finish a full AI transformation?
No. Ninety days is a planning cadence for a single-market, single-use case pilot and an evidence-based decision. Whether the work then expands depends on risk and on that evidence, not on the date.
How should AI content be written if we also care about GEO?
Give a definition, the steps, the conditions under which the claim holds, the source, the exceptions and a reviewable record. Do not invent precise metrics that have no source. Display or citation is still decided by the search system. See GEO content governance for the content job; do not treat this calendar as a ranking method.
Who may approve AI output for a live page or reply?
A merchant-assigned merchandiser, editor or support lead, according to current store roles. The model is not the approver. The program owner also cannot replace a market, privacy, product or permission review of that boundary. The record should include version, source, reviewer and time.
What should happen when an acceptance check fails?
Freeze new scope, keep the test case, input, output, log and version, verify whether the live store was affected, and return to the last approved baseline or to human handling. Continue or expand only after the evidence is repaired, the test is rerun and the relevant roles sign off.
How should we judge whether the pilot is working?
Start with control: factual corrections, unsupported claims, refused out-of-scope actions, complete logs and whether customers still reach a person. Then look at review hours and rework. An unsourced growth rate, a Search Console impression, or an AI Overview impression is not an acceptance standard.
Related work: AI customer support, knowledge and human handoff, AI agent workflows with facts, permissions and rollback, and GEO content governance.