Step 1
Collect each SKU's movement history over the reporting period, its product group assignment, the launch dates and seasonality notes the merchant records, and the slow-moving threshold the merchant applies.
Bounding decisions on a SKU start from habit, because nobody can show how quickly it moves inside its own product group. In this case, the immediate task is to analyze slow-moving inventory by relevant product group. The workflow should produce an inventory health analysis and prioritized actions drawn from the merchant's own movement records.
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.
Act as a Shopify operations specialist.
Help me analyze slow-moving inventory by relevant product group.
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: [movement history per SKU for the reporting period, product group assignments, launch dates and seasonality notes, and the merchant's slow-moving threshold].
Compare each SKU's movement rate against the other SKUs inside its own product group rather than against the catalogue as a whole, list separately the SKUs launched inside the period and those whose window falls in a recorded off-season, and flag as slow only those whose rate trails their own group after those effects are set aside.
Return an inventory health analysis and prioritized actions verified against the supplied records 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.Split the work into input, judgment, and deliverable phases. Verify each step's output before moving to the next.
Collect each SKU's movement history over the reporting period, its product group assignment, the launch dates and seasonality notes the merchant records, and the slow-moving threshold the merchant applies.
Compare each SKU's movement rate against the other SKUs inside its own product group rather than against the catalogue as a whole, list separately the SKUs launched inside the period and those whose window falls in a recorded off-season, and flag as slow only those whose rate trails their own group after those effects are set aside.
Deliver an inventory health analysis grouped by product group with each flagged SKU's rate, its group's rate and the exclusion reason where one applies, add prioritized actions, and reconcile the SKU count and movement totals with the movement history before publishing.
Cover decision rules, frequent misunderstandings, and required inputs so the team aligns on prerequisites before execution.
Because demand varies by category: a rate that is poor in one group is normal in another, and comparing everyone with the catalogue average flags entire groups at once. Grouping also separates genuine weakness from uneven demand across sizes, so the action lands on the SKU that is truly slow.
From the merchant's own movement records and review cycle, written down with the report so the next review measures the same thing. No fixed percentage is assumed, and if the threshold changes the report states both the old and the new basis for one period.
They stay in the file but are listed separately: a SKU launched inside the window has too little history to compare, and one measured in a recorded off-season looks slow for calendar reasons. Each excluded SKU carries its reason and the date from which it can be ranked.
Start with scenarios under the same topic, then expand into cross-topic matches suggested by similarity.
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.