The technical part of adding an AI sales assistant to a Shopify store is one script tag. Five minutes, reversible by deletion, no app development.
The install is also not where the outcome is decided. Teams budget their care for it anyway, and improvise the three decisions that actually determine whether the thing sells: what the assistant reads, what you tell it, and what you do with the first weeks of transcripts. Those three, in the order they should happen.
Decision one: what the assistant reads
Every answer the assistant will ever give is downstream of its product knowledge, so choose the source deliberately. There are three levels, and they are a sequence, not alternatives.
Reading the storefront live is the zero-setup level: the assistant browses your published store the way a shopper would. Its real purpose is evaluation. Before committing an afternoon to any tool, point it at your live store and watch it handle your actual products; this is also the cheapest way to discover that a vendor’s demo does not survive contact with your catalog.
Syncing the catalog is the production level: your product export (Shopify’s CSV, or the feed you already maintain for shopping ads) gives the assistant clean names, prices, stock, and links. Answers get faster and noticeably sharper because retrieval works from structured truth instead of scraped pages.
Plugging in a search you already tuned is the level for stores with history: years of Algolia synonyms and rankings are an asset, and a good assistant should sell through that index rather than replace it.
Whichever level you land on, the same rule pays for the effort: write product text like a salesperson, not a label. The assistant finds products by what descriptions mean, so “slim merino base layer, machine washable, warm enough for commuting until about freezing” is retrievable by a dozen real questions. “Great base layer!” is retrievable by none.
Decision two: the brief
Configuring the assistant is writing, not settings. The useful mental model is briefing a competent new hire on day one:
Who buys from you and what they care about. “Trail runners, mostly experienced, obsessed with weight and weather” changes every recommendation that follows.
How you talk: the phrases you use, and the ones you never want on your storefront.
Your policies, exactly as written: shipping zones and times, returns, warranties. These are half of everything it will be asked.
And the house rules for the hard moments: out of stock means offer the closest alternative; anger means hand off to a human; discounts and delivery dates are never invented. These rules are where trust is kept or spent, and they belong in writing before launch, not after the first incident.
Then set the first impression: a greeting in your voice and two or three starter prompts (“Help me pick a gift,” “What’s new?”). A blank chat box is a small interrogation; prompts tell shoppers what they are allowed to ask.
Treat the whole brief as a working assumption, not a constitution. You wrote it before meeting real shoppers. It will be wrong somewhere, and finding where is what the next phase is for.
Before customers: test like a skeptic
In the playground, run three families of questions. The vague one: “present for my dad, likes the outdoors, around 100 euros.” The precise one: “is the 38mm strap compatible with the 42mm?” And the trap: a product you don’t carry, a discount that doesn’t exist.
The trap is where the brief earns its keep. The same question, before and after one house rule:
You: Do you have a student discount?
Assistant, no rule written: Of course! Use code STUDENT10 at checkout.
There is no code STUDENT10. There never was.
Assistant, after “never invent discounts” went into the brief: We don’t offer one. The trail jacket you were looking at is in the sale section, though.
The only right answer to a trap is an honest no, ideally with a real alternative. When an answer misses, resist the urge to blame the model. In my experience the cause is almost always a missing line in the brief or thin product data, both fixable in minutes. Iterate until every answer is one you would happily see screenshotted in a review.
Then install: Shopify admin, Online Store, Themes, Edit code on the live theme, open layout/theme.liquid, paste the snippet before the closing body tag, save. Check two things on your phone in a private window, because that is where your shoppers are: the widget loads after the page, and a recommended product card lands on the right product. Removal, should you ever want it, is deleting the same snippet.
The first weeks: the transcripts are the product
Most teams skip this part, and it is worth more than every step above.
Read the transcripts. All of them, the first week; minutes a day. You are mining for three things: questions you never anticipated (add the answers to the brief), products shoppers asked for that you don’t stock (demand your sales data cannot contain, by definition), and answers that were weak or wrong (fix the data behind them, not just the symptom).
This loop is the actual return on the afternoon you invested. The assistant answers shoppers; the transcripts answer you.
After the first weeks, the failure mode inverts: teams stop reading and start tinkering, adjusting the brief on gut feel. Gut feel is how quiet regressions ship. Once the assistant is stable, changes deserve the same discipline as checkout changes: test the challenger against the current version and let shopper behavior decide.
What you are signing up for
An afternoon of setup, then fifteen minutes a week, indefinitely. Any vendor promising results without the second part is selling you the install, and the install was never the product. The product is a feedback loop between your shoppers’ questions and your store’s answers, and it compounds only if someone is reading.
If you want the zero-commitment first step, this is why we built Probedots to read a storefront live before anything is installed: the fastest way to know whether an assistant can sell your products is to watch it try.