01
Step 1
Gather the defined reorder rules with their trigger conditions, sellable stock, inbound purchase orders with expected arrival dates, supplier lead times, and the merchant's approval limit for automated orders.
Back to topic
Spark playbook scenarios · Spark: AI Store Assistant
Trigger replenishment actions from defined stock rules
Reorder rules exist on paper, but nobody checks each day which products have actually crossed their trigger. In this case, the immediate task is to trigger replenishment actions from defined stock rules. The workflow should produce a replenishment plan with timing and quantity rationale, using the merchant's stock, inbound orders and lead times.
Topic
Replenishment and Inventory Planning
Target keyword
shopify automatic replenishment
Copyable AI prompt
A prompt you can drop directly into Spark
First replace every [bracketed] placeholder with real store scope and constraints, then add any actual records or data you have, and paste it into your preferred AI assistant or Spark agent. Spark will follow this page's workflow to produce structured output and verification steps.
ai-prompt.txt
Act as a Shopify operations specialist.
Help me trigger replenishment actions from defined stock rules.
My store context is [describe the business, products and target audience].
My scope is [specify the affected products, pages, customers or reporting period]. Use these inputs: [the defined reorder rules with their trigger conditions, sellable stock, inbound purchase orders with expected arrival dates, supplier lead times, and the merchant's approval limit for automated orders]. Test each rule against current projected coverage to find the SKUs crossing their trigger today, compute each rule's suggested quantity after pack and minimum constraints, and route any triggered order above the stated approval limit, or resting on an unreliable rate or stale count, to review.
Return a replenishment plan with timing and quantity rationale for the specified task.
Show the relevant evidence or before-and-after examples and explain how I can verify the result.
If essential data is missing, ask for it and mark unsupported conclusions as unknown.
Do not invent metrics, product claims or customer facts.
For any publication, message, account or store change, use only connected tools within my explicitly authorized scope and report success only after verification; otherwise provide the draft or proposed steps.How to solve
A recommended resolution workflow
Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
02
Step 2
Test each rule against current projected coverage to find the SKUs crossing their trigger today, compute each rule's suggested quantity after pack and minimum constraints, and route any triggered order above the stated approval limit, or resting on an unreliable rate or stale count, to review.
03
Step 3
Deliver the triggered action list with trigger reason, quantity and destination supplier per SKU, then verify each trigger against the stock records and reconcile the action count with the rules defined.
FAQ
Common questions when running this scenario
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
What does testing a rule against coverage involve?
Each defined rule's trigger condition is evaluated against the SKU's current projected coverage, computed from sellable stock, committed and inbound quantities and the recorded sales rate, to find which products have crossed their line today. The test uses the same coverage basis the rule was written for. Rules whose trigger cannot be evaluated from the records are listed as undefined rather than guessed.
When does a triggered order go to review?
Any triggered order above the merchant's stated approval limit, and any SKU flagged for an unreliable rate or a stale stock count, routes to review instead of automating. Orders inside the limit proceed automatically, which bounds the cost of a wrong trigger. The review list names the rule and the reason for each held order.
How is a false trigger traced back to its rule?
Every triggered action records the rule fired, the coverage figure at that moment and the stock records used, so a wrong action traces to either a bad input or a badly written rule. The trace sits beside the action, not in a separate log. Fixing the input or the rule then prevents the same trigger recurring.
Related scenarios
Continue with adjacent or same-topic scenarios
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
Next step
Want these AI scenarios embedded directly into daily operations?
Ciwi Spark builds Shopify-native AI tools and agents around the workflows merchants actually run: research, ads, translation, and customer support. Stop rewriting the same prompts by hand.