Skip to content
Case study · Food and beverage manufacturing

Food manufacturer: an agentic sales system to reactivate customers

By analyzing a year of invoices, KINTO found that fewer than half of a food manufacturer’s customers drove almost all of its volume; we built a production WhatsApp agent, an AI calling pilot and a headless store that kept every URL.

By KINTO · Published

Figures, each with its source

  • tens of thousands (12 months)

    invoice lines analyzed

    Measured

  • ≈45% of customers account for ≈85% of volume

    customers who buy every month vs. volume

    Measured

  • ≈1 in 4

    conversations handled by the agent that end in an order (figure from our commercial proposal)

    Estimated

  • ≈98% on the same path

    store URLs kept through the migration

    Measured

Ranges or orders of magnitude where a figure could identify the client, each with its source.

How the transformation unfolded From the problem to what changed, in the five steps every KINTO case follows.

  1. Problem

    A food manufacturer with a standard online store, dozens of products and over a thousand registered customers handled everything by hand on WhatsApp.

  2. Signals

    Four signals: market, business, user experience and support.

  3. How we understood it

    We segmented a full year of invoices by repeat frequency and route, reviewed real conversations (including one lost sale) to turn each error into a testable rule, simulated dozens of customer scenarios before every release, and audited every URL before migrating.

  4. What we built

    A WhatsApp sales agent whose delivery date is computed by code, an outbound AI calling pilot, a delivery-route lookup service for agents, and a headless store that preserves the URL structure.

  5. Transformation

    The WhatsApp channel went from a bot on a local computer to a cloud service with complete orders and deterministic delivery dates, and the company began to see its customer base as actionable segments.

Before and after, by dimension Editorial levels from 0 to 4 read from the text of this case, never a figure drawn to scale.

  • Customer visibility

    Before

    Segments not visible (level 1 of 4)

    After

    Actionable segments (level 4 of 4)

  • WhatsApp channel

    Before

    Bot on a local computer (level 1 of 4)

    After

    Cloud service, full orders (level 4 of 4)

  • Delivery dates

    Before

    Promised wrongly (level 1 of 4)

    After

    Computed by code (level 4 of 4)

  • Online store

    Before

    Standard store (level 2 of 4)

    After

    Headless, cutover pending (level 3 of 4)

The four signals we read What the market, the business, the user experience and support were saying before KINTO built anything.

  • Market

    Ads were already running (over a third of sessions came from them) and branded search dominated: demand existed.

  • Business

    A long tail of customers was going cold, with a large group not buying for over three months.

  • User experience

    Three in four visits came from mobile, and products with many search impressions had very low clicks.

  • Support

    Several people answered WhatsApp by hand; orders arrived without e-invoicing data, and delivery dates depend on route and cutoff day.

How each error became a rule
  1. Invoice segments A full year, by frequency and route
  2. Real conversations Each error, a testable rule
  3. Simulated scenarios Before every release
  4. Code sets the date If the model contradicts it, the answer is regenerated

Connections

  • Invoice segments → Real conversations
  • Real conversations → Simulated scenarios
  • Simulated scenarios → Code sets the date

By analyzing a year of invoices, KINTO found that fewer than half of a food manufacturer’s customers drove almost all of its volume; we built a production WhatsApp agent, an AI calling pilot and a headless store that kept every URL.

Problem

A food manufacturer with a standard online store, dozens of products and over a thousand registered customers handled everything by hand on WhatsApp. One goal was to reactivate customers, but nobody could see which ones to reach. The sales team was stretched, and earlier automation attempts promised wrong delivery dates.

Signals

  • Market: Ads were already running (over a third of sessions came from them) and branded search dominated: demand existed.
  • Business: A long tail of customers was going cold, with a large group not buying for over three months.
  • User experience: Three in four visits came from mobile, and products with many search impressions had very low clicks.
  • Support: Several people answered WhatsApp by hand; orders arrived without e-invoicing data, and delivery dates depend on route and cutoff day.

How we understood it

  • Customer-base mining: a year of invoices segmented by repeat frequency (core, frequent, occasional, sporadic) and by delivery route. This showed who carries the business and who is leaving.
  • Review of real conversations, including a lost sale, to turn each error into a testable rule.
  • Customer simulator with dozens of scenarios that runs before every release.
  • Digital audit: inventory of every store URL before migrating, analytics and Search Console reviewed via API, and a review of the shopping feed.

What we built and why

  • WhatsApp sales agent (in production): advises, quotes, takes the order with billing data and notifies the salesperson and accounting. Code computes the delivery date: time cutoff, route day, holidays and weekends.
  • Outbound AI calling pilot to reactivate customers: campaigns segmented by value and recency, with the transcript and order written to the CRM.
  • A route lookup any AI can query: the delivery-route sheet turned into a query service for agents.
  • Headless store synced with the catalog, keeping the original URL structure (nearly all without a redirect), structured data, truthful FAQs, llms.txt and an own search that hands off to WhatsApp when there are no results.
  • Pay-for-growth proposal: a frozen per-customer baseline and fees only on incremental sales, auditable against the ERP.
  • Read-only layer on their ERP so agents could query real data without being able to write. The project did not move forward because of access restrictions; the layer remains a reusable asset.

Why this way: Delivery dates depend on time cutoffs, routes and holidays, and a language model gets them wrong. Code computes the date, and if the model contradicts the tool, the answer is regenerated.

Transformation

  • The WhatsApp channel went from a bot on a local computer to a cloud service with complete orders and deterministic delivery dates. Within months there were thousands of conversations handled and hundreds of logged handoffs to humans.

  • The company now sees its customer base as actionable segments (win-back, core) rather than a list.

  • The headless store was ready for cutover with no lost URLs.

  • invoice lines analyzed: tens of thousands (12 months) (measured)

  • customers who buy every month vs. volume: ≈45% of customers account for ≈85% of volume (measured)

  • conversations handled by the agent that end in an order (figure from our commercial proposal): ≈1 in 4 (estimated)

  • store URLs kept through the migration: ≈98% on the same path (measured)

What we don’t know yet

  • Effect on total sales: the agent’s conversion figure comes from our proposal and we have not audited how it was calculated; the new store’s cutover was still pending.
  • The calling pilot closed orders in tests, but no real, measurable campaign was launched.
Case studies

Related case studies

Have a problem like this?

Tell KINTO what is going on. The first conversation is to understand it, not to sell.

Book a call Contact