Domino's Pizza
Call Center Application
Call Center? Isn't Domino's a pizza company? Yes and yes, but also so much more. Domino's builds virtually every single piece of software above the stores (greater online ecosystem and ordering platforms) as well as the software inside of every single store. This includes seemingly mundane applications like a custom build Call Center software. This was originally built to facilitate faster phone orders, on behalf of franchises, to save labor time - letting franchise employees focus on making pizza, and not dealing with a constantly ringing phone. It was mostly adapted in the Global Markets (all non-USA markets) however was decided to be ramped up for US operations in 2025.
Approach
The challenge for me lied in getting a piece of software that hadn't seen a single update in 4 years ready to massive US call volume. On the surface it looked like a clean POS system, ready for use - all we needed to do was set up an authentication flow with our vendor. Little did I know... Our recently cloud migrations had unwittingly damaged the connections to almost all the underlying services - however the intermittent nature of the connection issues made it hard to diagnose. The address module for customer addresses used Google - not the normal Domino's store locator, meaning out of sync address formatting would cause frequent breaks placing an order. Any POS errors were missing labels, leaving agents confused. Clicking on menu items out of order would freeze the entire UI. Critical franchise data points were omitted from the heads up display. Bugs everywhere.
What Now…..
What was supposed to be a simple integration quickly spiraled into me building out an entirely fresh backlog, constant testing, breaking, and more testing, and ultimately requiring me to find available team members from every discipline to quickly band together. Backend Devs, UI Devs, Infrastructure, DBAs, QAs, Networking, the list goes on. In a matter of weeks this project went from simply onboarding some agents, to having to rebuild the plane while it was flying. We eventually found stability, and the vendor onboarding proceeded.
Key Learnings
- Digging up a service that hasn't seen support in several years is hard!
- We were teaming up with an external vendor who would onboard their agents to the platform - which ultimately made this a re-tooled B2B SaaS buildout. Working with this vendor and fielding the seemingly endless updates of newly documented breaks was tiring, but made the resolution all the more sweet.
- Don't promise a fresh service integration immediately after all the subservices have been migrated to a new cloud environment - at least not until every single component has been thoroughly vetted out.
- Identifying UI resources became a major lynchpin of the project. If you even "think" a UI dev will be required at any point, start looking for someone sooner rather than later. Better to have available bandwidth and not need it, than need it and not have it.
- I can safely say I now know more about the call center application than anyone, maybe even more than the team that first built it years ago - all from what was supposed to be a simply authentication project.