Pragmatic AI in grocery: 3 cases that work, 2 that don't

If you run technology for a grocery chain, the pressure to "add AI" this year isn't coming from the tech team. It's coming from the CEO, the board, the consultant who showed up at a meeting. It arrives as a vague mandate: "we need AI." No use case. No success metric. No defined budget beyond "let's start with something."

That mandate is the most expensive way to burn money in grocery enterprise today. I say that from experience, not cynicism: I've watched at least five chains in the region spend between forty and two hundred thousand dollars on AI projects that ended up shelved within six months — not because the technology failed, but because the use case was wrong from day one.

This post exists to flip that conversation. Here are three AI cases in grocery that actually work, with honest criteria to evaluate them. And two that almost never work, with the technical reason why. The goal isn't to sell a project — it's to give you a frame for saying no to the next nine vague AI proposals that will cross your desk this quarter.

Case 1 — Demand forecasting with local events

When it works: when you already have at least two years of sales history per SKU per store, and you want to improve replenishment-order accuracy over the heuristic method your purchasing team uses today.

When it doesn't: when your sales data has serious gaps, inconsistent formats, or your product master has unreconciled duplicate SKUs.

Demand forecasting with machine learning is probably the AI use case with the highest measurable ROI in grocery enterprise today. The reason is simple: every percentage point of forecast accuracy improvement translates into less perishable shrinkage, fewer stockouts, and less capital trapped in inventory. In a fifty-store chain with USD 80M-200M annual revenue, an 8% accuracy improvement over the current heuristic typically represents between USD 600,000 and USD 2.4M per year. Those numbers aren't hype — they're the math of grocery margins.

What separates an implementation that moves the business from one that doesn't is the quality of local features.

The local features that make the difference in Central America:

Local operating calendar. Mother's Day spikes dairy and bakery. Independence Day eve (September 14) spikes beverages and charcoal. Mid-month payday spikes mass categories in urban zones. Holy Week shifts the entire dynamic. Tropical storm season affects logistics. If your model uses only the Gregorian calendar, you're leaving 4 to 9 accuracy points on the table.

Weather per store. A rainy week in a highland branch affects perishables differently from a rainy week in the capital. Free historical weather APIs (Open-Meteo, NOAA) plug into the pipeline cheaply.

Neighborhood events. A national-team match, a local fair, a religious procession. These have measurable impact on specific SKUs at specific stores. The honest way to capture this is a manual calendar maintained by operations — plus a public events feed.

Competitor pricing. A weekly scrape of the catalogs of your two main local competitors can improve the model 2-5 points on price-sensitive SKUs (commodities like oil, sugar, rice).

The mistake that kills ROI on this use case is automating replenishment without human-in-the-loop in the first quarter. The right way: the model suggests, the purchasing team reviews and approves or adjusts. By day 90 you have data on how often the team modified the suggestion and why. By day 180 you can automate categories where the model matches or beats the team.

Case 2 — Semantic catalog search in Spanish

When it works: e-commerce with more than 5,000 active SKUs, where user behavior shows the internal search has a "zero results" rate above 8% or post-search bounce rate above 50%.

When it doesn't: small catalog (under 2,000 SKUs) or when most traffic lands on predefined categories and search is a marginal feature.

Spanish has a specific grocery search problem English doesn't: dense regionalisms in common categories. A shopper searches "blanquillos" and gets zero results because your catalog says "huevos." Another searches "papa" when your master records it as "patata." Keyword search fails. Semantic search solves this without your catalog team maintaining a manual synonym dictionary.

The stack we recommend:

// services/search/src/embeddings.ts
import { OpenAI } from 'openai';
import { Pool } from 'pg';
 
const openai = new OpenAI();
const db = new Pool();
 
// Indexing: runs once per SKU, then only on changes
export async function embedAndStoreProduct(p: Product) {
  const text = [
    p.name,
    p.brand,
    p.category,
    p.description,
    p.tags?.join(' '),
    // Critical regional aliases maintained by the catalog team
    p.regionalAliases?.join(' '),
  ].filter(Boolean).join(' . ');
 
  const { data } = await openai.embeddings.create({
    model: 'text-embedding-3-small', // 1536 dims, USD 0.02 / 1M tokens
    input: text,
  });
 
  await db.query(
    `INSERT INTO product_embeddings (sku, embedding, indexed_at)
     VALUES ($1, $2::vector, now())
     ON CONFLICT (sku) DO UPDATE SET embedding = $2::vector, indexed_at = now()`,
    [p.sku, JSON.stringify(data[0].embedding)],
  );
}
 
// Search: runs per user query
export async function semanticSearch(query: string, limit = 24) {
  const { data } = await openai.embeddings.create({
    model: 'text-embedding-3-small',
    input: query,
  });
 
  const result = await db.query(
    `SELECT sku, name, price, image_url,
            1 - (embedding <=> $1::vector) AS similarity
     FROM product_embeddings pe
     JOIN products p USING (sku)
     WHERE p.active = true
     ORDER BY embedding <=> $1::vector
     LIMIT $2`,
    [JSON.stringify(data[0].embedding), limit],
  );
  return result.rows;
}

Honest costs for a chain with a 30,000-SKU catalog and one million searches per month:

• Initial indexing: USD 1-3 (one-time, embeddings for 30k products).
• Incremental re-indexing: USD 5-15 per month (changes only).
• Production search: USD 12-25 per month for query embeddings.
• Postgres with pgvector already running: zero additional cost over the existing database.

Total: under USD 50 monthly in AI infrastructure. The typical measurable improvement: post-search conversion rises 12-30%, zero-results rate drops below 1%.

Why pgvector over Postgres is the right answer for almost every chain: you already have Postgres running, you already have backups and compliance configured, you already have a team that operates it. Pinecone or Weaviate make sense at hundreds of millions of vectors — that's not your case.

Case 3 — Internal assistant for store managers

When it works: chains with more than twenty stores where manager and assistant-manager turnover is high, and where operational procedures are documented but scattered across PDFs, intranets and SharePoint folders nobody consults.

When it doesn't: when your managers are senior, stable, and already fluent with procedures.

This is the most underestimated LLM use case in grocery enterprise. It isn't glamorous. It doesn't pitch well in a keynote. But the ROI per hour saved is direct and measurable.

The concrete problem: a new store manager needs to answer in five minutes operational questions an experienced person would answer from memory. "How do I process a return where the customer paid with a card from a bank we don't integrate with?" "What's the closing procedure on a Sunday with no supervisor?" "How do I escalate a pest report in a cold room?" The answer lives in some operating manual. Finding it takes fifteen minutes. Multiplied by twenty new managers a year, multiplied by four or five questions weekly — that's hundreds of lost hours.

The pattern that works is RAG over operating manuals with strict scope — not an open chatbot.

// services/store-assistant/src/rag.ts
import { Anthropic } from '@anthropic-ai/sdk';
import { getRelevantSops } from './retrieval';
 
const anthropic = new Anthropic();
 
const SYSTEM = `You are an assistant for store managers in a supermarket chain.
Strict rules:
- Only answer based on the operating procedures provided in context.
- If the answer is NOT in context, say exactly: "This requires consultation with your regional supervisor. Call [shift number]."
- Never invent phone numbers, deadlines or authorizations.
- If the question involves monetary authorization above local threshold, say to escalate.
- Reply in Spanish, max 4 paragraphs.`;
 
export async function ask(question: string, storeId: string) {
  const sops = await getRelevantSops(question, { topK: 5, storeId });
 
  const context = sops
    .map((s) => `### ${s.title} (section ${s.section})\n${s.body}`)
    .join('\n\n');
 
  const response = await anthropic.messages.create({
    model: 'claude-haiku-4-5-20251001',
    max_tokens: 800,
    system: SYSTEM,
    messages: [
      {
        role: 'user',
        content: `Manager question: ${question}\n\nRelevant procedures:\n${context}`,
      },
    ],
  });
 
  return {
    answer: response.content[0].type === 'text' ? response.content[0].text : '',
    sources: sops.map((s) => ({ title: s.title, section: s.section })),
  };
}

Three technical details that separate a useful implementation from a dangerous one:

1. Explicit scope in the system prompt. "Only answer based on the procedures provided." This reduces hallucinations to near zero — the model doesn't invent procedures.

2. Explicit fallback. When context isn't sufficient, the model defers to the supervisor. It doesn't improvise. That fallback sentence is the difference between a reliable tool and a lawsuit.

3. Sources in the answer. Every reply cites the manual section it came from. The manager can verify. It's auditable.

The cost: under USD 200 monthly in Claude Haiku API calls for a fifty-store chain with ten daily queries per store. The measurable improvement: average time to resolve operational doubts drops from fifteen minutes to under one, and the regional support team sees inbound call volume drop 30-50%.

What almost never works

And now the unpopular part. Two use cases get proposed constantly in grocery enterprise and almost always fail in production.

Public chatbot without scope

The typical project: "let's put a chatbot on the website that helps customers with anything." Sounds nice. Fails in production.

The technical reasons are three. First, without strict scope, the chatbot answers things it shouldn't — from nutritional advice to legal recommendations — and that's direct legal exposure for the chain. Second, per-query costs scale fast when public (bots, scrapers, abuse). Third, customers with real problems prefer a human and get frustrated with the bot, increasing support cost rather than reducing it.

If you want to improve customer support experience, a scope-restricted assistant for your internal support team works. A public chatbot without scope, doesn't.

Critical predictions without human-in-the-loop

See case 1, but stronger: automating replenishment of perishable goods based solely on model predictions, without human review, is the recipe for emptying cold rooms or filling warehouses in exactly the wrong season. Models fail on unprecedented events — and grocery has unprecedented events every four or five months (pandemic, major storm, government decision).

The simple operating rule: if a wrong prediction costs more than USD 5,000 per decision, a human signs before execution. Period.

How to decide if your case is one or the other

Before spending the first dollar on any AI project, three questions your tech team must be able to answer with numbers:

1. What is the success metric and what is its baseline today? "Improve the customer experience" isn't a metric. "Raise post-search conversion from 14% to 20%" is. If you can't define this, you don't yet have a use case.

2. What happens if the model is wrong 5% of the time? If the answer is "we lose money but the system continues," it's a candidate. If the answer is "there's serious legal or reputational risk," you need mandatory human-in-the-loop.

3. Do we have the clean, complete data the model needs? In grocery, this is usually the real blocker — not the technology. If your product master has duplicates, if your sales history has gaps from past migrations, if competitor prices aren't captured — no model will save you.

If all three have clear answers, the project is worth doing. If any doesn't, the project is premature optimization disguised as innovation.

If your CEO is asking you to "add AI"

If you reached this post because you have to put together an AI proposal for the board next quarter — the right answer isn't to pick a trendy use case. It's to pick a use case with measurable ROI and bounded risk. Forecasting with human-in-the-loop, semantic search to solve the Spanish problem, an internal assistant for store managers — these are three defensible bets. Anything else starts with the hard question above.

In our AI engineering retainer we help chains do exactly this: move from "we want AI" to a concrete project with a metric, estimated ROI, bounded risk and a phased plan. We don't sell platforms — we design the use case, build it in production, and stay close through calibration.

If this resonates, let's talk. Thirty minutes. I call you.