Introducing the Universal Managed Agents API.Read the announcement
Case study

Automating Domino's local competitor pricing research

Cole PattersonMember of Deployment Staff6 min read
Table of Contents

Domino's is the world's largest pizza company, with more than 22,500 stores across over 90 markets and a business built around delivery and carryout.

Within Domino's CMO office, local competitor pricing analysis is a recurring market intelligence task. The team needs to understand how competitor prices vary across markets, stores, ordering channels, delivery modes and discounts.

The Brainbase team embedded with Domino's CMO office to build a pricing research agent from the ground up. The agent collected competitor prices across local ordering surfaces, applied market-specific rules, filled the team's pricing workbook, and noted the uncertain cases.

97%
Final benchmark accuracy
52%
Lower cost per source
41 min
Faster turnaround per run

Accuracy against cost per source

$3.00$2.50$2.00$1.50$1.0040%50%60%70%80%90%100%Cost per sourceAccuracyv1v2Claude Opus 4.6 → Sonnet 5v3Improved browser runtimev4Corrected Burger marketv5v6v7v8Playbook adjustmentv9Corrected Pizza marketv10v11 · 97%Precise discount checking: banners, BOGO, app-only
Each point is one agent version, scored by manual review; hover a point for its numbers and what changed. The line steps along the Pareto frontier: each version on it was cheaper and more accurate than the last. Greyed versions fell back on one axis and sit off the line. Cost per source is the cleanest spend metric because the number of sources changed between runs; cheaper runs sit further right.

The problem

Competitor pricing research is highly manual because the “right” price depends on local context.

A human analyst has to check competitor websites, delivery platforms and app-like ordering flows; select the correct location; compare delivery and takeaway pricing; identify the cheapest qualifying item; account for promotions or unavailable products; and then transfer the result into a customer workbook.

The work is repetitive, but it is not simple. A wrong market, store, channel, promotion or menu assumption can make an otherwise completed source inaccurate.

Domino's
“Competitor pricing is highly local, and small details matter. Brainbase helped us handle more of that complexity in a structured, repeatable way.”

The core challenge: Domino's needed a faster and more repeatable way to collect local competitor pricing without losing the judgment required for edge cases. The metrics that mattered were accuracy, cost per source, average runtime, and whether discount search could be automated at all.

The agent

Brainbase built an agent to automate the recurring collection process. The agent reads the target list, navigates competitor ordering surfaces, checks the correct local store or market, interprets delivery and takeaway pricing, identifies relevant promotions, fills the pricing workbook and flags exceptions for human review.

  1. Target list
  2. Local browsing
  3. Price interpretation
  4. Workbook fill
  5. Human review

The agent turns a manual browsing task into a repeatable pricing collection process, and it runs on Claude Sonnet 5 on Brainbase. Version 1 ran on Claude Opus 4.6; every version from the second on has run on Sonnet 5, and the accuracy gains came from the playbook, not the model.

What success looked like

Domino's needed this to work like a real analyst workflow, not a demo. Each run had to find the right local store, compare the right ordering channel, handle promotions and missing items, and return a workbook the team could actually review.

The benchmark was built from the team's own work. The target list was the real list of stores, competitors and ordering channels the analysts cover, and the answer key was the workbook as the analysts corrected it after each run. Accuracy is the share of pricing cells the agent got right against that corrected workbook, judged by manual review. The benchmark then tracked whether each version was getting closer to the bar: how accurate the results were, how long the run took, what it cost per source, how complete the workbook was, and where a human still needed to step in.

MeasurementWhy it matters
AccuracyMeasures output quality
RuntimeMeasures turnaround speed
Brainbase creditsMeasures total compute spend
Dollars per minuteShows run intensity
Cost per sourceNormalises cost across changing scope
Run notesExplains what changed between versions

This made the project measurable as an iteration loop, not just a one-time automation demo.

Accuracy improved across versions

The agent improved as each run exposed new edge cases and failure modes. Accuracy increased from 41% to 97% across the benchmark period. The largest improvements came from making the playbook more specific: better location matching, clearer delivery and takeaway handling, stronger discount logic, and more explicit rules for unavailable stores or ambiguous menu items.

Improvement areaExample change
Location matchingMore explicit store and market checks
Channel handlingClearer distinction between delivery and takeaway
Promo logicBetter treatment of discounts, vouchers and app-only campaigns
Gap handlingCleaner treatment of unavailable stores or missing items
Workbook completionMore structured output and fewer blank fields

Cost efficiency improved

Cost per source is the cleanest spend metric because run scope changed over time. Across the benchmark, cost per source decreased from $2.11 to $1.01, a reduction of approximately 52%.

This matters because competitor pricing is recurring work. Lower cost per source means the agent can cover more locations, markets and competitors without scaling manual effort at the same rate.

Human work shifted from collection to review

The manual process took at least two hours per run. The agent averaged approximately one hour and nineteen minutes, reducing elapsed turnaround by about 41 minutes per run.

Agent runtime against the manual baseline

0 min40 min80 min120 min129v1122v2104v3101v495v599v684v781v877v988v1071v11Manual baseline, 120 min
Minutes per run. The dashed line is the manual workflow at its fastest, two hours. The agent averaged 1 hour 19 minutes across the benchmark.

Runtime fell for a specific reason. Early versions scraped every section of every site. Later versions tracked which sections a run visited without finding anything, narrowed the discount search to the sections that actually carry deals, and replaced run-level instructions with site-by-site ones: for one site, check the banners first, then the hot deals section, then regular-priced pizza; for another, only the BOGO and discount sections. Skipping the full scrape of each site was the largest single time saving.

The largest change was the type of work being done. Before Brainbase, the human analyst had to manually collect every data point. After Brainbase, the agent handled the repetitive collection work while the human focused on reviewing exceptions, correcting edge cases and improving the next run.

The improvement loop

Each run created feedback that improved the next version.

  1. Agent run
  2. Agent review
  3. Corrections
  4. Playbook update
  5. Better next run

This loop was especially important because competitor pricing includes judgment-heavy edge cases: promotions, unavailable stores, local menu differences, channel-specific prices and source-specific quirks. The system improved because human corrections were converted into more specific playbook rules. The last step, version 11, was precise discount checking: banners, buy-one-get-one offers and app-only campaigns, checked the way an analyst would.

Why it matters

Brainbase gave Domino's a more repeatable way to monitor competitor pricing. The value was not just that one workbook could be completed faster. The value was that competitor intelligence became easier to refresh, audit and improve over time.

Domino's
“What stood out to me was the improvement loop. [...] Each run surfaced issues, and those learnings made the next version more accurate.”
  • Fresher market visibility

    When pricing research takes less time and costs less per source, the team can refresh competitive data more often across priority markets instead of treating each analysis as a heavy manual project.

  • More coverage without proportional headcount

    Lower cost per source makes it practical to expand the number of stores, competitors, channels and delivery modes monitored without asking analysts to repeat the same browsing by hand.

  • A stronger operating loop

    Each run produced reviewed outputs, exceptions and corrections that fed back into the playbook, turning pricing research from a static spreadsheet task into an improving operational system.

Where this leaves Domino's

Competitor pricing research at Domino's is no longer a task an analyst starts from a blank browser tab. It is an agent the team runs, reviews and improves: eleven versions in, accuracy went from 41% to 97%, cost per source fell by half, and each run hands back about 41 minutes. The analysts' time now goes to the exceptions, which is where their judgment was always needed.

Two things made that possible. The first is that the benchmark was built from the team's own work, so every version was scored against what the analysts would have produced themselves. The second is the loop: because every correction became a more specific playbook rule, the agent got better at exactly the cases that had been going wrong, and the improvements compounded from one run to the next.

A note on the numbers. Accuracy was judged by manual review against corrected workbooks, and a few runs had no corrected workbook to compare against. The scope of a run changed as coverage grew, which is why cost per source is the figure to trust rather than total spend.

Looking ahead

What began as one workbook has become a standing capability. The CMO office now has a way to ask a pricing question about any market and get a reviewed answer back the same day, and the cost of asking keeps falling with each version. The plan is to use that: refresh priority markets on a schedule rather than when someone has a free afternoon, and extend coverage to more stores, competitors and ordering channels without adding to the analysts' load.

The agent itself has a clear next set of versions. Alongside accuracy, cost and runtime, the benchmark will track review time, corrections per run, coverage and cost per completed pricing cell, so the loop can be measured as tightly as the output. The playbook will keep absorbing the edge cases the analysts find, which is how it got from 41% to 97% in the first place.

The pattern is not specific to pizza. Any recurring research task where the right answer depends on local context, and where a human currently pays for that context with hours of browsing, can be run the same way: build the benchmark from the team's real work, ship a first version, and let the corrections drive the next one. Domino's CMO office has more of those tasks, and this is the first of them.

Related posts