Value prop 01
Classify at scale — read every row, not a sample
Free-text data is where the useful signal hides and where human attention runs out first. Nobody reads 4,000 return reasons. FlightDeck does, on every run, and turns the text into a column you can filter, chart, and alert on.
- Return reason clustering — every return assigned one of eight labels: quality defect, not as described, wrong item, size/fit, changed mind, late delivery, duplicate order, or other
- Seller feedback sentiment — each review classified positive, neutral, or negative
- Only unclassified rows are processed, so a re-run costs nothing for data already labelled
- Rows are batched per API call — 25 at a time for returns, 20 for feedback — which keeps throughput high and token spend predictable
- Labels are written back to the source table, so every downstream report and alert can use them immediately
This is the part that changes what's possible, not just what's fast. "Alert me when quality-defect returns rise 40% week over week" is not a rule you can write without a machine reading the returns first.
Value prop 02
Explain what happened, in sentences a client can read
A number tells you something moved. It doesn't tell you the story. The portfolio analysis workflow reads your actual product data — titles, ratings, review counts, prices, availability — and returns narrative insight rather than restated metrics.
Output is structured into four parts, so it drops straight into a client update:
Portfolio analysis outputJSON
{
"summary": "Champion products perform well with loyal customers,
but inventory problems are limiting growth.",
"insights": [ // what's actually happening
"Customer satisfaction is strong — most products hold 4.2+
ratings with hundreds of reviews",
"Five top-rated products are out of stock, losing revenue
during peak season"
],
"opportunities": [ // what to do about it
"Restock bestsellers — top 5 have 100+ reviews each"
],
"risks": [ // what needs attention now
"Three products at 3.0–3.5 rating — investigate complaints
before further decline"
]
}
- Scoped to an agency or narrowed to a single client
- Focus areas are configurable — pricing trends, review quality, availability, and more
- Token usage is returned with every response, including cache hits, so cost is never a mystery
Value prop 03
Ask your own questions — dynamic reports
The fixed workflows cover the recurring cases. When you need something they don't, you write the question instead of filing a feature request. A dynamic report is a report whose logic is a prompt: you describe what you want to know, and it runs on demand or on a schedule like any other report.
Example promptsPlain English
// Competitive posture
"Compare our pricing against the Buy Box winner for each ASIN.
Flag anything where we're more than 8% above and still losing."
// Launch triage
"Which products launched in the last 90 days are underperforming
relative to their category, and what do they have in common?"
// Client-ready narrative
"Summarize this week's changes for a non-technical client.
Lead with anything that costs money."
- Three execution modes: on demand, once at creation, or recurring on a cron schedule
- Returns a summary, insights, and recommendations as structured data — not a wall of prose
- Report data is passed to the model as context, so answers are grounded in your numbers rather than generic advice
- Lives alongside standard reports, so it feeds the same alerts and the same delivery groups
Value prop 04
Audit and recommend — findings, not just figures
Any standard report can opt into an AI post-processing pass that runs immediately after execution. In audit mode the model reads the whole result set at once and produces a structured verdict — the shape a workflow can act on.
Audit output — stored against the report runJSON
{
"summary": "Spend is concentrated in three underperforming campaigns.",
"action_items": [ "Pause 'Brand Defense — Broad', ACOS 71% over 30 days",
"Shift budget to 'Category Exact', ACOS 18%" ],
"flags": [ "4 ASINs advertising while out of stock" ]
}
Three post-processing modes are available, and they differ in what they write back:
| Mode | Reads | Writes |
|---|
sentiment |
One text column, row by row |
A sentiment label per row, back into the source table |
clustering |
One text column, row by row |
A cluster label per row, back into the source table |
audit |
The full result set as one block |
A single JSON verdict stored against that report run |
Because sentiment and clustering write into the source table, the enrichment is permanent. Every later report that reads that table gets the AI columns for free — you pay to classify a row once.
Value prop 05
Trigger downstream work — the output is an input
An insight that stops at a dashboard has not saved anyone any time. Every workflow output can route through a delivery group, and delivery groups reach eight destination types — including the ones that start real automation.
Zapier
Webhook
REST API
Slack
Email
SMS
S3
Shared Reports
The first three are the automation surface. A Zapier destination takes a standard Zapier webhook URL, which means an AI-generated finding can open a ticket, update a sheet, post to a channel, create a task, or start a multi-step Zap — without anyone reading it first.
- Webhook and Zapier destinations support four output formats: structured JSON, plaintext, HTML snippet, or a full HTML email document
- Structured JSON is the one to pick when a machine is downstream — the receiving system parses fields instead of scraping prose
- One group can hold several destinations, so the same finding can hit Slack for visibility and a webhook for action simultaneously
- Groups are reusable across reports and alerts — change the responder once, not rule by rule
This is what makes the human-in-the-middle decision real. Route low-severity findings straight to automation and high-severity ones to a person — the difference is which delivery group the alert points at.
Value prop 06
Coming Soon
Trigger history & memory — an alert that remembers what it already told you
Today each trigger is evaluated on its own. That's the right default, and it's also the ceiling: a workflow with no memory will tell you about the same stockout on Monday, Wednesday, and Friday with equal urgency, and it can't tell a new problem from an old one that never got fixed.
Trigger history closes that gap. Every firing becomes a durable record — the metric values, the analysis, the routing decision, the outcome — and the next evaluation of that alert starts by reading the ones before it.
The AI reviews its own previous analysis
Before producing a new verdict, the workflow loads the alert's prior triggers and asks a question it currently cannot: has anything actually changed? The answer becomes a status on the trigger itself.
New
No comparable prior trigger. Treat as a fresh problem and analyse from scratch.
Unchanged
Same condition, same cause, same state as last time. Suppress the notification rather than repeat it.
Escalating
Same problem, measurably worse than the previous trigger. Raise severity even though the threshold is identical.
Regressed
Previously resolved and now back. The earlier fix didn't hold — which is a different conversation from a first occurrence.
"Unchanged" is the one that pays for the feature. Repeat notifications about a problem your team is already handling are the fastest way to teach people to ignore alerts. A workflow that can recognise its own prior analysis can stay quiet — and staying quiet is a decision that requires memory.
Your notes become part of the AI's context
Most of the reason a given alert doesn't matter this week lives in somebody's head. Trigger notes move it somewhere the workflow can read it — annotate an alert or an individual trigger, and that context is supplied to the model on every subsequent evaluation.
Alert · Inventory — Weeks of Cover · Trigger history
Mar 2New
4 ASINs below 3 weeks of cover. Sell-through up 22% after the promo — demand-driven, not a supply failure.
🙋 Priya, Account Lead
Supplier delay confirmed. Restock ETA Mar 14 — expect this to keep firing until then.
Mar 6Unchanged
Same 4 ASINs, same cause. Priya's note puts restock at Mar 14 — no new information and no action available. Notification suppressed.
Mar 17Escalating
Restock ETA has passed and cover fell to 0.8 weeks — worse than Mar 2, and the stated mitigation didn't land. Escalated to a human.
- Standing notes on the alert itself — context that always applies, like "Q4 seasonality, ignore dips under 15%"
- Trigger notes on a single firing — the episodic detail, like a supplier ETA or a client approval
- Notes carry their author and timestamp, so the model knows how old the context is and your team knows who to ask
- A note that supplies a mitigation gives the workflow something to check against next time — which is exactly what turns the Mar 17 trigger above into an escalation instead of another repeat
Status: this section describes planned functionality, not what ships today. Current behaviour: each trigger is evaluated independently, firings are recorded, and prior analyses are not yet fed back into the next evaluation. Ask us where this sits on the roadmap before you plan around it.
Value prop 07
Task catalog — what you can actually hand it
Concretely, the work these workflows take off your team's plate:
📦Return reason clustering
Turns thousands of free-text return reasons into eight countable categories you can trend and alert on.
→ reason_cluster column
💬Feedback sentiment
Labels every seller feedback entry so sentiment shifts show up as a metric, not a hunch.
→ positive | neutral | negative
🧭Portfolio health narrative
Reads product data and writes the story — sentiment, pricing, inventory health, market position.
→ summary · insights · opportunities · risks
📣Sponsored ads audit
Reviews campaign performance as a whole and returns specific actions, not a spend table.
→ action_items · flags
❓Ad-hoc analysis
Any question you can write down, run once or on a schedule, grounded in your report data.
→ dynamic report
✍️Client-ready summaries
Converts a week of movement into language a non-technical stakeholder reads without translation.
→ HTML email · Slack · shared report
Worth being straight about the boundary: these workflows classify, summarize, audit, and route. Executing a change on the marketplace — repricing, editing a listing, cancelling stock — happens in the system you connect downstream, under whatever approvals you set there.
Value prop 08
Setting it up in the dashboard
Three separate things to configure, depending on which workflow you want. None of them require an engineer, though the post-processing block is JSON rather than a form.
A. A dynamic report — your own prompt
1
Open the report creator
From the Reports page, start a new report. The creator opens with three tabs: Standard, Dynamic, and Canned Templates.
Reports → New Report
2
Choose the Dynamic tab
Give it a title and description, then write your LLM Prompt — the question you want answered from the report data. This is the whole configuration; there is no query to build.
3
Pick an execution mode
On-demand runs when viewed, on-creation runs once, and scheduled runs on a cron expression — 0 9 * * 1 for Monday mornings at 9am.
B. AI post-processing on a standard report
Post-processing is configured on the report's execution config as an ai_analysis block. No schema change is needed — the field is additive, and a report without the block behaves exactly as before.
execution_configJSON
{
"mode": "scheduled",
"schedule": "0 9 * * 1",
"ai_analysis": {
"type": "sentiment", // sentiment | clustering | audit
"field": "customer_comments", // column to read
"output_field": "sentiment", // column to write
"prompt_template": "Classify the sentiment of each comment…"
}
}
C. Routing the output somewhere useful
4
Create a delivery group
Name the group, then add destinations. Each destination is a channel plus its address — a Slack incoming webhook URL, a Zapier webhook URL, an email address, an S3 bucket, and so on.
Delivery Groups → New Group
5
Set the output format
For webhook and Zapier destinations, choose Structured JSON when a machine is receiving it, or one of the plaintext/HTML formats when a person is.
6
Point an alert at the group
Create an alert on the report, set the condition and severity, and select the delivery group. Alerts are evaluated in the same pass as the report run — there's no second schedule to manage.
Alerts → New Alert
Order that works: get the report producing clean output first, add the AI step, then wire delivery last. Each stage is independently testable, so when something looks wrong you know which layer to look at.
Value prop 09
Cost and control — the boring parts that matter
AI features are easy to demo and expensive to operate carelessly. The guardrails here are deliberate:
- Failures are non-fatal. If a Claude call fails, the report still succeeds and returns its data — the error is logged, not propagated. An AI outage degrades enrichment; it doesn't take your reporting down.
- Row caps are enforced. Post-processing sends at most 200 rows per run, so a runaway result set can't produce a runaway bill.
- Classification is incremental. Only unclassified rows are sent. Re-running a report doesn't re-pay for labels you already have.
- Prompt caching is on. System prompts are cached, and cache read/write tokens are reported separately from input tokens.
- Token usage is returned with every analysis — input, output, cache creation, and cache read — so per-run cost is observable rather than inferred.
- Every alert that fires is recorded with its context and payload. That history is the audit trail behind any automated action taken downstream.
One honest caveat: AI classification is very good, not infallible. Labels are stored as ordinary columns, so a wrong one can be corrected in place — and for anything irreversible or client-facing, route to a person rather than straight to automation.