Actions worklist
In plain English
This is your to-do list, written for you automatically.
Different parts of the app spot different problems — a product that's priced wrong, a customer about to stop buying, carts people abandoned. Instead of you hunting through ten screens, they all report into this one list.
The clever bit is the order. The list puts things at the top when they're worth a lot of money and quick to fix. So the first row isn't just "the biggest problem" — it's the best use of the next half hour you have.
You don't need to decide what to work on. Just start at the top.
How to use it
- Click "Daily Ops" in the left-hand menu. It opens on the Actions tab.
- Read row 1 — the title tells you what's wrong, and the amount tells you what it's worth.
- Click the row. It takes you straight to the screen where you fix it.
- Fix it, then come back and click "Mark done."
- If a row isn't worth doing — a discontinued product, say — click "Dismiss." It disappears and stops counting toward your totals.
- Repeat until you're out of time. Whatever you didn't reach was worth less than what you did.
⏱ ~10 min/day · 💳 Starter+ · 🎯 Highest-value work first, every time
Why this matters for your business
Every serious commerce platform eventually grows a recommendations problem. Each engine is built by people who care about their domain, so each one ships its own "issues" tab with its own severity words, its own sort order, and its own idea of what "important" means. Individually they're all reasonable. Collectively they're unusable, because nothing can compare a "critical" SEO finding to a "high priority" pricing finding to a "⚠️ needs attention" catalog finding. There is no shared unit.
The Actions worklist exists because the shared unit is money. Not severity labels, not engine opinions — the amount at stake, discounted by how sure the engine is, divided by how much work it takes you to fix. That produces a single ordering across ten domains that is defensible: the row above always deserves your attention before the row below.
The practical consequence is that you stop making prioritization decisions at all. You don't compare an SEO finding to a pricing finding, because the list already did. You work down from the top and stop when the hour is gone, knowing that whatever you didn't reach was worth less than what you did.
What this typically unlocks
| Outcome | Typical result |
|---|---|
| Engine tabs checked per day | 1 instead of 6–10 |
| Findings that never get seen | ~0 — one queue, nothing hides in a sub-tab |
| Time spent deciding what to do | ≈ 0 — ranking is the decision |
| Duplicate work across the team | Eliminated — one row per real problem, one owner |
| Clicks from finding → fix screen | 1 |
| Backlog grooming time | 0 — findings retire themselves |
What you actually get
Each row in the worklist carries a consistent set of fields — regardless of which engine produced it.
| Field | What it tells you |
|---|---|
| Domain | Which part of the business — leaks, pricing, voice, readiness, content, and so on |
| Severity | Critical, Warning, or Info |
| Title | The finding, in one line |
| Body | The detail, including what's missing or what changed |
| Amount at stake | Recoverable money, in your currency — present when the finding is economic |
| Scope | Whether it's shop-wide or scoped to one product |
| Detected | When the signal first appeared |
| Fix link | Where you go to resolve it |
The ten domains
| Domain | Example finding |
|---|---|
| Revenue Leaks | "47 abandoned checkouts — ~$2,340 recoverable of $23,400 at stake" |
| AI Readiness | "Make 'Linen throw — sand' ready for AI shopping agents. Readiness 44/100. Add: Rich description, Price set, Product image." |
| AI Visibility | Discoverability gaps on AI-driven surfaces |
| Customer Voice | Recurring themes surfacing across reviews, tickets, and survey text |
| Pricing | Margin erosion or a price-guard breach |
| Market Intel | Category or competitive-position shift |
| Content | Content decaying and due for a refresh |
| Retention | Replenishment window open, or churn risk detected |
| Merchandising | Assortment or collection problems |
| Executive | Cross-engine strategic findings |
How it works (without the technical bits)
Scoring, in detail
score = (value at stake × confidence) ÷ effort
Value at stake. When a finding carries a recoverable amount, that amount is the base. When it doesn't — an AI-visibility regression has no natural currency figure — a notional value stands in based on severity:
| Severity | Notional value | Effect |
|---|---|---|
| Critical | 1,000 | Ranks alongside a four-figure money finding |
| Warning | 250 | Ranks alongside a mid-size leak |
| Info | 50 | Present but rarely at the top |
Without this substitution, non-economic findings would sort below every trivial $60 leak on the list — which is exactly the failure mode where important structural problems go unread for months.
Confidence is a 0–1 value set by the detecting engine and defaults to 0.5 when unspecified. A statistically-derived finding carries high confidence; a heuristic carries low. Halving confidence halves the score.
Effort divides:
| Tier | Divisor | What it means |
|---|---|---|
| One-click | 1 | A wired fix exists — the platform can do it |
| Quick | 2 | Minutes of manual work |
| Manual | 4 | Real investigation |
When an engine doesn't declare effort, it's inferred: a finding with a wired fix is treated as one-click, everything else as manual.
Worked example.
| Finding | Value | Confidence | Effort | Score |
|---|---|---|---|---|
| Abandoned carts, recovery send wired | $2,340 | 0.8 | One-click (1) | 1,872 |
| Funnel drop-off, needs investigation | $6,200 | 0.3 | Manual (4) | 465 |
| Critical AI-visibility drop | (notional 1,000) | 0.9 | Quick (2) | 450 |
| Product missing price + image | $890 | 0.7 | Quick (2) | 312 |
The $2,340 finding beats the $6,200 one by 4×, and that's the point of the formula.
Ties break on severity first, then on most-recently detected.
Deduplication — one row per real problem
Every finding has an identity key:
domain : kind : scope : scope-id
For example, agentic_readiness : readiness_gap : product : 8123456
— one stable key for "this product isn't agent-ready," regardless
of how many times it's re-scored.
Two things follow. Within a single detection run, duplicates collapse before writing: the survivor is chosen by higher severity, then higher score, then more recent. And across runs, re-detection updates the existing row instead of adding another. A finding sharpens over time; it doesn't multiply.
This is why the readiness scorer can re-run daily against 4,000 products without ever producing 4,000 new rows a day.
Where each row sends you
| Domain | Fix page |
|---|---|
| Revenue Leaks | Cart Recovery |
| AI Readiness | AI Readiness tab |
| AI Visibility | Growth Intelligence |
| Customer Voice | Customer Voice |
| Pricing | Auto-Price |
| Market Intel | Competitor Analysis |
| Retention | Second Purchase |
| Executive | Decision Intelligence |
| Merchandising | Growth Intelligence |
Product-scoped findings override all of the above and deep-link to that product's editor. A readiness gap on one SKU takes you to that SKU, not to a filtered list you then have to search.
Rows only render as clickable when the destination is a page your plan actually includes — so you never click through to a screen you can't use.
Lifecycle
| Status | Set by | In the worklist? | In the money rollup? |
|---|---|---|---|
| Open | Detection | Yes | Yes |
| Snoozed | You | Yes | Yes |
| Actioned | You — "Mark done" | No | No |
| Dismissed | You — "Dismiss" | No | No |
| Resolved | Automatic | No | No |
Auto-resolution is per-domain and matched to how fast that signal goes stale — 7 days for pricing and readiness, 21 for voice, retention, and category, 14 as the default. Leak findings ignore the timer and resolve on fact: the cart converted or expired, or stock came back.
Pagination
The full actionable set is read and ranked in one pass, then served a page at a time at 10, 20 (default), or 50 rows. Ranking always spans the entire set, so page 1 is the true top of the list. If you action the last item on a page, the view falls back to the last valid page rather than going blank.
Permissions and audit
| Action | Permission |
|---|---|
| View the worklist | growth:read:all |
| Mark done / Dismiss / Reopen | growth:manage:all |
Solo merchants bypass both automatically. Every status change records the acting user's email; background transitions record a stable system identity instead, so the audit trail is never blank. Reads and writes are scoped to your shop at the query level — a finding can only ever be touched by the store that owns it.
Real merchant scenarios
Scenario A — The queue that replaced a spreadsheet
Setup. Beauty brand, 900 SKUs. The ops lead maintained a weekly spreadsheet compiled by hand from six engine tabs. It took ~90 minutes every Monday and was stale by Wednesday.
With the worklist. The spreadsheet was deleted. The team worked the top 10 rows each morning.
| Week | Rows actioned | Recoverable closed |
|---|---|---|
| 1 | 34 | $8,900 |
| 2 | 21 | $4,100 |
| 3 | 12 | $2,600 |
| 4 | 9 | $1,900 |
The shape of that curve is the real result. Week 1 cleared a backlog nobody knew existed. By week 4 the list had reached steady state — roughly what the business generates in a week. Nine rows on a Monday is a healthy store, not a quiet one.
Scenario B — Severity vs. score
Setup. Electronics retailer sees two rows:
[Critical] AI visibility dropped on 12 category queries
[Warning] 88 abandoned checkouts — ~$4,200 recoverable
The Warning ranks above the Critical.
Why. The visibility finding scores on the notional critical value (1,000) at 0.6 confidence with quick effort → 300. The abandoned-cart finding scores on $4,200 at 0.8 confidence with a one-click fix → 3,360.
Was that right? Yes. The recovery send ran that afternoon and brought back $3,100. The visibility drop was real but structural — it took three weeks of content work, and starting it on Tuesday instead of Monday cost nothing. Severity describes how alarming a finding is; score describes what to do first. They are not the same question.
Scenario C — Dedupe under a bad import
Setup. Pet-supplies merchant ran a bulk import that stripped product types across 1,400 products, then re-ran it twice trying to fix it.
Without dedupe. Three runs × 1,400 products = 4,200 rows, and a worklist nobody could use.
With dedupe. 1,400 rows — one per product — each updated in place by the later runs, with severity escalating on the subset that also lost price data. The merchant filtered to critical, found the 210 products AI agents genuinely couldn't sell, and fixed those first.
Scenario D — Reopening a dismissal
Setup. A margin finding on a seasonal SKU was dismissed in January as "expected, clearance pricing."
In March the same SKU came back to full price, and the guard re-detected a breach — this time a genuine supplier cost issue. Because the identity key was the same, the existing row was refreshed and reopened rather than a new one created, carrying its history: dismissed in January, re-detected in March.
Why that matters. The buyer could see this had happened before, which changed the conversation with the supplier from "your price went up" to "your price has drifted twice this year."
Scenario E — When the list is empty
Setup. A mid-market merchant opened Daily Ops and saw zero open actions. Their first assumption was that something was broken.
It wasn't. They'd worked the queue consistently for six weeks, their catalog was fully agent-ready, and no leaks were open. The Pulse still showed revenue driven and agent-ready percentage, confirming the engines were running.
The lesson. An empty worklist is a positive result and a readable one — because findings auto-resolve, "empty" means "nothing is currently wrong," not "nobody has groomed this in months."
Best practices
✅ Work top-down, stop when time runs out. The ordering is the prioritization. Skipping around undoes the benefit.
✅ Use severity as a filter, not a sort. Filter to Critical when you have 10 minutes; otherwise trust the score ordering.
✅ Dismiss with intent. A dismissal is a business judgment that corrects the recoverable total. Leaving a known non-issue open inflates a number your team relies on.
✅ Assign growth:manage:all to named owners. Reading should
be broad; status changes should be attributable.
✅ Check the detected-at date on low-ranked rows. A finding that's been open 12 days in a 14-day domain is about to auto-resolve — don't spend the afternoon on it.
✅ Set page size to 50 during a backlog clear-out, and back to 20 for daily work.
❌ Don't sort by amount and start at the biggest number. That ignores confidence and effort — the two things that decide whether you'll actually finish.
❌ Don't leave rows open as reminders. They aren't tickets; they'll auto-resolve and your reminder disappears. Use Automations for recurring work.
❌ Don't dismiss an entire domain because it's noisy. Tune the owning engine's thresholds instead — dismissals are per-finding and the domain will keep emitting.
❌ Don't read the recoverable total as forecast revenue. Conservative recovery rates are already applied; it's a prioritization figure, not a projection you can bank.
Plan tiers
| Capability | Free | Starter | Pro | Agency | Enterprise |
|---|---|---|---|---|---|
| Ranked worklist | — | ✓ | ✓ | ✓ | ✓ |
| Leak + readiness domains | — | ✓ | ✓ | ✓ | ✓ |
| Voice, pricing, content, retention domains | — | — | ✓ | ✓ | ✓ |
| Executive + market-intel domains | — | — | ✓ | ✓ | ✓ |
| One-click fixes from a row | — | — | ✓ | ✓ | ✓ |
| Product deep-linking | — | ✓ | ✓ | ✓ | ✓ |
| Page size up to 50 | — | ✓ | ✓ | ✓ | ✓ |
| Role-separated view vs. act | — | — | ✓ | ✓ | ✓ |
| Cross-store worklist roll-up | — | — | — | ✓ | ✓ |
Frequently asked
Why is a Warning above a Critical? Score, not severity, drives the order. A high-confidence, one-click, high-value Warning genuinely should be done before a low-confidence, manual Critical. Severity still breaks ties and still filters.
Can I change the ranking formula? Not directly — a stable, explainable ordering is the point. You influence it by tuning thresholds and confidence in the owning engines, and by which fixes you wire up (a wired fix moves a finding to one-click effort, which quadruples its score).
A finding I dismissed came back. Why? The underlying condition was re-detected after being genuinely resolved and recurring. It returns on the same identity key with its history intact, so you can see it's a repeat.
How many findings does it hold? The ranked read covers up to 1,000 actionable findings per shop — far above steady state for any store, because findings auto-resolve rather than accumulating.
What if two engines disagree about the same product? They produce different domains and different kinds, so they're separate rows. Dedupe only collapses findings that are genuinely the same finding.
Does dismissing tell the engine to stop? No. Dismissal is a decision about that finding, not a rule. To stop a class of finding, adjust the owning engine's configuration.
Can I export the worklist? Findings are available programmatically for reporting and warehouse sync — see the Developer API.
Why do some rows have no money figure? Because not every problem has an honest currency estimate. Those rank on their severity's notional value rather than being given a fabricated number.
See also
- Daily Ops overview — the hub and Executive Pulse
- Weekly Plan — the curated top-5 view of this queue
- Revenue Leaks — where the money findings come from
- AI Readiness — the readiness scoring behind those rows
- Automations — converting repeat actions into rules
- Decision Intelligence — strategy on top of the queue