labor_efficiency
0.94
Rev/labor-hour −22% vs. cluster, staffing mismatch at 11a–1p peak
Every empty shelf is a lost sale. Ward runs it directly off your Looker feed, read-only, with no changes to your BI.
Ward can query Looker via API or connect directly to the underlying database. Either way, Ward monitors while your team browses.
Agents run against your baselines overnight. These are what they flagged without being asked.
labor_efficiency
0.94
Rev/labor-hour −22% vs. cluster, staffing mismatch at 11a–1p peak
inventory.fresh
0.89
Fresh fill 83%, backroom replenishment lag at 2–4p
promo.lift
0.81
BOGO crackers cannibalized Brand Y by 28%, net category +6%
Re-baseline Store 37 schedule against true peak, raise replen window to 1p, and review the BOGO before next cycle.
Connect external systems. Ward AI maps the schema and drafts the cleaning rules.
| Name | Type | Last sync |
|---|---|---|
sap_pos_transactions | import | 2m ago |
sap_inventory_shrinkage | import | 2m ago |
sap_labor_scheduling | import | 14m ago |
retail_inventory_weekly | import | 1h ago |
retail_google_ads_daily | import | 1h ago |
retail_meta_ads_daily | import | 1h ago |
retail_ga4_website_daily | import | 1h ago |
Move data from sources into models on a schedule. Describe the sync; Ward AI builds it.
| Name | Source | Model | Status | Schedule |
|---|---|---|---|---|
sync_sap_pos_transactions | sap_pos_transactions | pos_transactions | enabled | hourly |
sync_sap_inventory_shrinkage | sap_inventory_shrinkage | inventory_shrinkage | enabled | daily |
sync_sap_labor_scheduling | sap_labor_scheduling | labor_scheduling | enabled | daily |
sync_retail_inventory_weekly | retail_inventory_weekly | inventory_weekly | enabled | weekly |
sync_retail_google_ads_daily | retail_google_ads_daily | google_ads_daily | enabled | daily |
sync_retail_meta_ads_daily | retail_meta_ads_daily | meta_ads_daily | enabled | daily |
Ward does not replace Looker. Ward watches the same data Looker visualizes and proactively alerts when something changes. Your dashboards stay. Ward adds intelligence.
Credentials are read-only and locked to the objects you name. Ward cannot reach a table you did not grant it, and write access is opt-in per object rather than implied by the connection.
Ward queries Looker in place and keeps no second copy. Your region, your retention policy, and no staging warehouse in the middle.
Every connector carries a schema contract. A source that changes shape fails the contract and stops the pipeline, rather than quietly writing wrong rows until someone notices the numbers moved.
Ward monitors on-shelf availability across your entire estate and flags stores or categories dropping below threshold.
Ward tracks expected vs actual on-shelf availability at the store-category level and escalates when fill rate drops below configurable thresholds.
Definitions resolve through the semantic layer, so a number here reconciles with the dashboard your team already publishes instead of disagreeing with it quietly. How the layer works →
Estate fill rate at 94.2%, up 1.2pp vs last week. Stores 22 and 37 dropped below 85% threshold. Fresh produce is the driver.
On-shelf availability below 92% costs a typical chain 4% of revenue annually. — IHL Group
Agents on your own data fail the security review, not the demo. The model is never the problem. The problem is that nobody can say what the agent is allowed to reach, what it already did, or what happens when it is wrong.
The agent sees the Looker objects you declared on the source and nothing else. Scope is enforced at query time, not in the client.
Read-only until you grant a write action explicitly, per object. A grant leaves a record naming the agent, the caller and the rows it touched.
One audit log covers every person and every agent in the tenant, so a reviewer answers one question against one system rather than correlating two.
Describe the job in plain English. Ward AI proposes the agent and the exact permissions it would need against your Looker objects, and the proposal sits there until a person approves it. Nothing runs on a draft.
Every finding it returns carries the SQL that produced it. If the query is wrong you can see that it is wrong, which is the only way a data team ever trusts one of these.
What fill rate monitoring off Looker looks like once it is live. Retail is where Ward is deployed, not what Ward is.
30,000+ SKUs · stores
Ward's morning fill rate card shows the estate is healthy overall, but flags seven stores below threshold. It attributes root cause for each: late DC deliveries for some (already en route), a supplier fill rate issue on dairy for others, and an afternoon depletion pattern in produce at two stores suggesting insufficient replenishment labor during the mid-shift window. The VP acts on the labor issues and monitors the rest in under five minutes.
The grocery build →3,000+ SKUs · locations
Mid-week with the next delivery two days out, Ward detects dozens of stores on pace to stock out on top tobacco SKUs, a category representing a major share of inside gross profit. Ward issues fill rate alerts with recommended emergency orders from the nearest distribution point. Store managers receive automated alerts with pre-built order lists.
The convenience build →15,000+ SKUs · locations
Ward reveals that a significant share of top styles have broken size runs across the chain, popular sizes depleted while other sizes sit. Ward recommends urgent inter-store transfers for the highest-revenue styles and a size curve recalibration for the next allocation cycle. Operations executes within 48 hours to protect at-risk revenue.
The fashion build →Your platform team owns the connection, the definitions and the policy. These are the teams that consume what comes out of it.
Supply Chain
Estate-wide on-shelf availability with category drill-down.
What they see →Store Operations
Which stores dropped below threshold, by hour and department.
What they see →Merchandising
Category-level fill tied to revenue at risk.
What they see →| Measure | Effect | Why |
|---|---|---|
| Time to Insight | Proactive, no login | Explains why metrics moved before anyone checks a dashboard. |
| Anomaly Detection | Inter-refresh coverage | Catches deviations between Looker dashboard refresh cycles. |
| Decision Velocity | Root cause attached | Every anomaly card includes cause analysis; no drill-down needed. |
| Data Utilization | Unused models activated | LookML dimensions and measures queried beyond built dashboards. |
Ward can query Looker via API or connect directly to the underlying database. Either way, Ward monitors while your team browses.
Ward reads Looker API for query results, Underlying database (direct) and LookML model metadata. Credentials are read-only and scoped to the objects you name, so Ward cannot reach a table you did not grant it.
No. Ward queries Looker in place and holds no second copy of your data. Nothing is exported to run Fill Rate Monitoring, and your residency and retention policy are unchanged by connecting Ward.
Every connector carries a schema contract. When a source changes shape the contract fails loudly and the pipeline stops, rather than writing wrong rows into your warehouse for a week before anyone notices the numbers moved.
Ward monitors on-shelf availability across your entire estate and flags stores or categories dropping below threshold. Ward tracks expected vs actual on-shelf availability at the store-category level and escalates when fill rate drops below configurable thresholds.
Yes. Every figure Ward reports carries the query that produced it, resolved through the semantic layer, so it reconciles with the dashboard your team already publishes rather than disagreeing with it quietly.
Only what you declared. An agent is scoped to named tables and cannot reach past them, it is read-only unless you grant a write action explicitly, and every query, tool call and result is logged against the agent identity that made it.
Typically VP / Director of Supply Chain, Director of Store Operations and VP / Director of Merchandising. They read the output; your platform team owns the connection, the definitions and the policy that produced it.
Ward's morning fill rate card shows the estate is healthy overall, but flags seven stores below threshold. It attributes root cause for each: late DC deliveries for some (already en route), a supplier fill rate issue on dairy for others, and an afternoon depletion pattern in produce at two stores suggesting insufficient replenishment labor during the mid-shift window. The VP acts on the labor issues and monitors the rest in under five minutes.
Deploying is free. You pay 5% of the model compute it uses, and nothing else. No call required to find out whether this works on your data.
Read-only to start · your LLM keys · SOC 2 Type II underway · or book a call directly
Tell us about your operation. We’ll show you the problems Ward catches, and the ones your current tools miss.