How Freddy's Built a Pricing Command Center with AI and Domo

Imagine you've just finished a massive data cleanup project, every price across 600 restaurant locations finally matches your source of truth, and you're ready to move on with your life. Then you discover the truth wasn't actually the truth. That's where Freddy's Frozen Custard & Steakburgers found itself, and it's why the restaurant chain stopped treating pricing governance as a project and started treating it as an always-on system.

In the Domo BUILD 2026 session, From Manual Cleanup to AI Monitoring: Scaling Enterprise Pricing Audits, Sean Thompson, VP of IT at Freddy's, walked through how his team transformed pricing governance from manual fire drills into a continuous, agent-driven monitoring approach. If you're managing pricing across multiple locations, channels, or systems, you'll walk away with a practical framework for building your own pricing command center, regardless of which tools you use.

Key takeaways

• Pricing governance works best as a continuous loop (audit, detect, correct, prove), not a one-time cleanup project
• Your "source of truth" can be wrong too—governance must include fixing upstream data, not just downstream errors
• API confirmations aren't always reliable; continuous monitoring catches drift that system acknowledgments miss
• If humans can see an issue in the data, that same data can feed an agent to automate the fix
• Proving automation value requires logging every fix with before/after states and measuring both direct ROI and operational "return on enterprise"

Build a continuous loop, not a one-time fix

Why treating pricing as a project guarantees you'll repeat it

Freddy's learned early that automation works best when you first understand the underlying process, then build something that runs continuously—rather than doing a single cleanup and walking away. With 600 locations, tens of thousands of price points across multiple delivery channels, and prices originally keyed in by hand, they needed a system that never stopped checking.

"You automate what you hate, but you don't wanna innovate on a mess. You've got to understand that process," said Sean. "That's the real path to success."

The team built a pricing center in Domo that runs four functions continuously: auditing, detecting, correcting, and proving. They iterated on this structure repeatedly, which made it easier to scale the governance workflow across all locations and price points.

You can apply this approach to your own pricing governance by:

• Mapping your current correction process: Before automating anything, document how you currently find and fix pricing errors. What triggers a review? Who makes corrections? How do you verify the fix worked?
• Identifying your single source of truth: Determine which system or dataset should be the authoritative reference for every price point. This becomes your baseline for all audits.
• Designing for continuous operation: Build your monitoring to run on a schedule, not on demand. The goal is catching drift before anyone notices—not reacting to complaints.

Trust your audits, not your APIs

When system confirmations lie, continuous monitoring catches the truth

Here's something any developer has probably experienced: an API confirms a change went through, but it never actually took. Freddy's ran into this "phantom price problem" where prices were programmed, the API said they went live, and then... nothing happened. The data drift was hiding in plain sight.

"Any developer out there has probably experienced this once or twice where an API just straight up lies to you," said Sean.

This led to a critical realization: they could never stop checking. The continuous checks caught mismatches that system confirmations missed entirely. Even more surprising, the audit exposed that the source of truth itself was sometimes incorrect, forcing them to fix upstream data and rerun the entire correction cycle.

To build verification into your own monitoring layer:

• Don't trust system acknowledgments alone: Build validation that checks the actual business outcome (the price a customer sees), not just the API response
• Include upstream data in your governance scope: Your audit should flag when the source data itself looks wrong, not just when downstream systems diverge from it
• Set up continuous checks on a schedule: Data drift can appear without warning and disappear just as mysteriously. Scheduled monitoring catches issues that spot-checks miss.

Measure the silence, not just the saves

Proving automation value when the best outcome is nothing happening

Agents, scripts, and platform credits aren't free. Freddy's knew they had to prove the return on investment, which meant logging everything. They captured before and after states for every fix, attached a dollar value to each correction, and built a ledger that justified the ongoing cost of the system.

But they also measured something harder to quantify: the return on enterprise. This meant counting the fixes that nobody ever noticed, like the manual war rooms and price sweeps that didn't have to happen because the system caught issues automatically.

"Instead of chasing prices, our teams are able to focus on the guests," said Sean. "That's a true return on enterprise."

The speaker also offered a governance warning worth remembering: "Silence is not compliance." When things are working and you don't hear complaints, that's not proof the system is functioning correctly. You still need measurement and monitoring to confirm it.

Here's how to prove your automation value:

• Log every action with timestamps and states: Capture what the data looked like before the fix, what triggered the correction, and what it looked like after
• Assign dollar values to each fix: Even rough estimates help justify ongoing costs and demonstrate cumulative value over time
• Track operational time saved: Count the meetings, manual reviews, and fire drills that didn't happen because the system handled issues automatically
• Report on both categories: Direct ROI (dollars saved per fix) and return on enterprise (operational focus shifted from cleanup to core work)

Once the Freddy's team could visualize and validate issues clearly, they framed the next step as presenting that same data to an agent: "If we can see it in the data, if we can present it like this tool [...] that same data that we can present to our teams, we can present to an agent and make them go out and do the fixes."

Catch Freddy's full Domo BUILD session

Freddy's pricing command center works because they stopped treating governance as a destination and started treating it as infrastructure. The continuous loop of auditing, detecting, correcting, and proving means drift gets caught before it becomes a crisis. Building verification into the monitoring layer—rather than trusting API confirmations—means phantom prices don't slip through. And measuring both direct ROI and operational "return on enterprise" means the value of automation is visible even when the best outcome is silence.

You don't need the same tools to apply these principles. What matters is designing your pricing governance as a system that runs continuously, validates outcomes rather than acknowledgments, and proves its value through rigorous logging. That's how Freddy's built a pricing command center with AI and Domo, and it's a framework you can adapt to your own environment.

Ready to see the full breakdown of how Freddy's built this system? Watch the complete session from Domo BUILD 2026 to get the detailed walkthrough and more context on their approach.