An AI e-commerce stack needs three connected jobs: capture product interest, check stock, and answer customer questions from approved facts. Each job needs clear inputs, a useful result, and a person who handles exceptions. Routine steps can run automatically; prices, policies, access, and difficult cases still need an owner.
Imagine a shopper signs up for news about a travel mug. An email is queued. Before it goes out, eight mugs sell. Can the store stop an offer based on old stock, while still answering an existing customer's order question correctly?
That handoff matters more than the number of bots you buy. This guide follows Willow Trail Goods, a fictional store, through it. All messages, quantities, and outputs are illustrative. The design has not been tested as a live integration. Linked provider documentation was checked on 5 October 2026.
Define three jobs and one owner for each record
Willow Trail Goods sells a blue travel mug with SKU MUG-BLUE. A SKU identifies a product variant. The store uses one commerce platform, one email tool, and one helpdesk. These are roles in the design, not a required shopping list.
Scroll sideways to see all columns.
| Job | Inputs | Useful result | Boundary |
|---|---|---|---|
| Product enquiry and lead capture | Approved product facts, shopper's question, signup choice | A grounded answer, product interest, and an allowed next step | No invented claims, discounts, or consent |
| Inventory check and sync | Inventory item, location, current available quantity | A checked stock record and a decision to allow or hold the offer | No model-generated quantity or competing stock writer |
| Customer support | Approved policy, current product data, verified order details when needed | An answer or a handoff with context | No unsupported delivery promise or unapproved order change |
For this pilot, the store owns inventory, the email tool owns subscriber status and sends, and the helpdesk owns conversations and handoffs. A shared record can pass facts between them. It should not become another system that decides how much stock exists.
You may use AI for the first and third jobs. Stock checks usually need fixed rules and software connections. A reusable skill can explain the method to a compatible agent, but its instructions do not create an API connection or enforce permissions.
Follow one product through the stack
The owner approves a product campaign while available stock is at least six mugs at the location that serves online orders. Six is this store's campaign rule, not a platform default or a guarantee of availability.
- Start with 12 available mugs. The product page has approved measurements, care instructions, and price.
- Answer a product question. A shopper asks whether the mug fits a car cup holder. The bot gives the approved base width and asks the shopper to compare it with their holder. It offers a signup for product news. The shopper chooses email marketing, and the email tool records that choice.
- Stock falls to four. Eight mugs sell. An inventory-change notice starts a check. The integration reads the current quantity for the right item and location, then pauses the product offer.
- Check again before sending. The sending workflow checks current subscriber status and the product's stock rule. It holds the queued offer because four is below six. It records the reason.
- Answer an order question separately. Another shopper asks about an existing order. Support verifies the shopper and reads that order's status. A paused campaign does not mean the order is cancelled, delayed, or shipped.
Four mugs can still be available to buy while the campaign is paused. The campaign threshold and the product's selling state are different facts. Support should answer from current store data, not translate “campaign paused” into “out of stock.”
The send-time check is a design requirement. Your email tool or integration must support a check close to the actual send, including messages already queued. If it only checks when someone enters a campaign, it does not meet this rule. Keep those sends under review until you have a tested way to hold them.
1. Give the lead bot a useful, narrow job
Start with shoppers who contact the store: a product question, signup form, or back-in-stock request. The bot can answer and record interest. It does not bring visitors to the store by itself or turn every email address into a qualified lead.
For the mug page, use instructions like these:
Answer from the approved product facts. If a needed detail is missing, say so. Ask at most one useful follow-up question. Offer the correct signup form if the shopper wants updates. Record interest in MUG-BLUE. Let the form and email system record marketing consent. Do not promise a discount, product fit, stock reservation, or restock date.
Suppose the fictional product page lists a 7 cm base width. A useful answer is:
The mug's base is 7 cm wide. Please compare that with your cup holder's opening and shape. I cannot confirm the fit without those details. Would you like a link to the product information?
The result should contain the shopper's question, product interest, source page, and next allowed step. It needs a subscriber ID only if a signup actually happened. Do not collect contact details just to answer a product question.
Keep a support request, a request for one restock notice, and a general marketing signup separate. Store the requested message and channel. Check the email system's current status before sending; an earlier signup may have been withdrawn.
Shopify's contact collection guidance says promotional content should go to customers who agreed to marketing. Its Forms settings let merchants collect consent or choose not to subscribe people who submit a contact form. Check the settings you use; a product-interest tag is not a consent record.
Approve the message template and its claims before the pilot. The bot may suggest a relevant approved message. The email workflow checks whether it can send it.
2. Make stock checks fixed and traceable
Read the stock count from the system that owns it. An AI model can explain a mismatch, but it should not decide a quantity from a conversation or an old event.
In this example, the integration reads store inventory and updates a campaign gate: a small record saying whether the offer may proceed. It does not write a new stock count back to the store. If you later connect a warehouse system, decide which system owns quantities before enabling writes.
Shopify's inventory model tracks quantities for an inventory item at a location. Check the variant, item ID, location, and quantity type. Total physical stock is not necessarily the quantity available to sell online.
Use three states for the offer
Scroll sideways to see all columns.
| State | Meaning | Campaign action |
|---|---|---|
ready |
A trusted, fresh read meets the campaign stock rule | May proceed if the subscriber and message checks also pass |
paused |
A trusted read shows stock below the campaign floor | Hold this product offer |
unknown |
The read failed, expired, or cannot be matched to the right item and location | Hold the offer and flag the check |
A record for our fictional example could look like this:
SKU: MUG-BLUE
Inventory source: store, online warehouse location
Quantity type: available
Available quantity: 4
Campaign floor: 6
Last successful read: 2026-10-05 10:15 UTC
Gate: paused
Reason: stock below the campaign floor
Next check: inventory change or scheduled source check
Record when the source was successfully read. An event's arrival time does not show how fresh its stock value is. Set a maximum age for the read and define what happens when it expires. A failed refresh must not leave an old ready state active indefinitely.
Treat an event as a reason to check
A webhook is a notice from another system that something changed. Use it to start a current source read, rather than subtracting stock again for every delivered notice.
Shopify documents that webhook deliveries can arrive out of order and are not always guaranteed. It recommends periodic source checks, often called reconciliation jobs. Its guidance also covers checking delivery signatures and ignoring duplicates. Shopify webhook guidance
Ask whoever builds the integration to handle these cases:
- The same notice arrives twice: it must not cause a second stock change or send.
- An older notice arrives later: it must not restore an outdated stock state.
- Two checks run together: an older read must not overwrite the result of a newer one.
- A notice is missed: a scheduled source check must still find the change.
These are requirements to test in the connected software. Writing them into a skill is not proof they work.
Add inventory writes only when the job needs them
If a warehouse owns the count, it may need to update the store. That is a different job from reading stock for a campaign.
Shopify's inventory write documentation says absolute quantity updates should come from the source-of-truth system. It describes a comparison with the existing quantity to detect concurrent changes, and an idempotency key for retries. That key helps avoid repeating the same operation; it does not replace the comparison check. Check the API version your integration uses before implementing either.
When a write fails or reports a conflict, do not blindly replace the newer quantity. Fetch the current state, follow the approved correction process, and record the result.
A stock check does not reserve an item
Even a fresh check can become old between sending an email and a shopper buying. The campaign gate reduces unsupported offers; it cannot guarantee that every recipient can buy the item or prevent all overselling.
Check inventory tracking, product-page availability, and checkout behavior separately. Shopify lets merchants continue selling when out of stock. Make that choice deliberate. Avoid “reserved for you” or a firm availability promise unless the store actually supports it.
3. Let support use the right source for each answer
Support needs approved policy for general questions and current, verified records for personal ones. A return-policy page cannot tell a shopper where their parcel is now.
For this pilot, allow product answers and order lookup. Route damaged-item claims, missing tracking, policy exceptions, and requests for a person to a monitored human queue. Keep refunds, address changes, and cancellations outside the first pilot.
As a provider example, Gorgias AI Agent on Chat documents sign-in before answering with personal order details. It uses knowledge such as help articles and website content. The current guide requires a connected Shopify store and an active AI Agent subscription. This is an example to assess, not a tested recommendation for Willow Trail Goods.
Gorgias also documents handoff topics that always go to a human, plus handoffs when it lacks a reliable answer. Check how that works in your chosen channel. A handoff setting still needs a team that receives and handles the ticket.
Suppose fictional order WT-1042 is marked packed, with no carrier scan. After verifying the shopper, a grounded answer is:
Order WT-1042 is marked packed. I cannot see a carrier scan or confirmed delivery date yet. I can pass this to our team to check.
“Packed” must not become “shipped.” A stock change or queued campaign is not evidence about that order.
The handoff should include the request, verified order ID if available, source checked, check time, and unanswered question. Assign a queue owner and an expected response process, including outside business hours. Do not promise an instant human reply if nobody is available.
Order actions need a separate end-to-end check. Gorgias documents Shopify order actions, but notes that cancelling an order or editing an address in Shopify does not automatically pass that change to third-party fulfillment apps. A successful store update alone may leave the warehouse working from the old order.
Test the handoffs before enabling live actions
Test one SKU, one form, one campaign, and one support topic. Write the expected outcome for each case before connecting real customers.
Scroll sideways to see all columns.
| Test case | Expected result |
|---|---|
| Valid signup; stock above the floor | Approved message becomes eligible after current checks |
| Form submitted without the needed marketing consent | Product question may be answered; promotional message is held |
| Shopper unsubscribes after the message is queued | Send-time subscriber check blocks it |
| Stock falls from 12 to four after queuing | Offer is held; the system does not falsely label four as zero stock |
| Stock read fails or passes its age limit | Gate becomes unknown; the stock-linked offer is held |
| Duplicate, older, or missed inventory notice | No repeated action or stale overwrite; scheduled checks find missed changes |
| Shopper asks about another person's order | No personal details are disclosed; verification or a human route is offered |
| Order is packed with no carrier scan | Support does not invent a shipping or delivery status |
| Human handoff is requested | Ticket reaches the correct queue with context and an owner |
Also test recovery. When stock rises again, fetch a new state and recheck subscriber status. Confirm that the message is still relevant and approved. Resuming the gate should not release every old queued offer or send the same message twice.
Run a small pilot and measure the full job
Fill in this card before the pilot:
Variant and online fulfillment location:
Inventory source and quantity field:
Campaign floor and maximum read age:
Consent source and approved message:
Which actions may run automatically:
Human review and exception owner:
Where sends, checks, and handoffs are logged:
Who can pause the workflow and how:
Conditions for resuming:
Pilot review date:
Begin with drafts and reports. Compare them with the store's source records. Then enable one bounded action, such as pausing an eligible product offer when stock falls. Test the actual send path before allowing automatic sends. Keep a person responsible for exceptions.
Measure both mistakes and useful work:
- Correct decisions: eligible messages sent, blocked messages held, and order answers matching the source.
- Failures: unsupported claims, consent errors, stale reads, duplicate actions, and handoffs that never reach a person.
- Missed useful work: eligible offers held for the wrong reason and routine questions unnecessarily sent to people.
- Human effort and cost: review, corrections, upkeep, subscription fees, usage, and paid connections. Record setup hours separately.
Compare the full task with the store's current process. A gate that holds every message has not proved the workflow works. A quick support reply that creates extra correction work has not saved the team time.
If a required rule fails, pause that action, fix the cause, and test fresh cases. Expand one product or support topic at a time after the pilot meets its rules.
Choose the next connection from the task
Map one product's enquiry, signup, stock check, send, and support handoff. At each step, name the source, the allowed action, and the person who takes over. That gives you a plan you can test with a provider or integration builder.
If you are still choosing tools, use our guide to choosing an AI bot. Compare candidates on that one job before buying a wider stack.