Order Fulfillment and Fleet Management

The existing restaurant POS was designed years before off-premises dining became a meaningful part of casual dining. It handled the core restaurant transaction well, but it was never designed for the additional workflows required to manage pickup and delivery. The goal was not to replace the POS. It was to extend it with a new operational platform that could be delivered quickly, work reliably inside the restaurant, and evolve as the off-premises business grew.

The platform was designed around a resilient restaurant edge. A POS Agent isolated the legacy POS and its file-based integration model from the new platform, translating POS events into a common OPD domain model. A local API, SQL Server database, and restaurant applications handled fulfillment and delivery workflows without depending on continuous connectivity to centralized systems. Google services provided geocoding and routing capabilities, while the architecture later connected to the Enterprise Cloud Platform for centralized configuration, deployment, and other shared services.

The engineering approach emphasized performance, reliability, modularity, testability, and long-term maintainability. Clear separation of concerns, well-defined interfaces, and deliberate use of design patterns kept components loosely coupled and extensible. Testing, deployment automation, observability, and security were treated as integral parts of the platform rather than concerns added later.

What began as a seven-month MVP continued to evolve as off-premises dining became a larger and more sophisticated part of restaurant operations. The original architecture remained the foundation as new capabilities, operational intelligence, and connections to the broader OPD ecosystem were added over time.

• A capable foundation from the start: The MVP established much of the core operating model: guest information, delivery eligibility, driver availability, dispatch, routing, mileage and toll information for driver reimbursement, and the restaurant-side workflows required to manage pickup and delivery.
• Better quoting and delivery decisions: Fast-follow capabilities introduced increasingly sophisticated calculations for expected ready and delivery times, giving restaurant teams better information to quote guests and manage fulfillment. Business-defined guardrails and overrides kept operational judgment in the process as the algorithms matured.
• More sophisticated fleet intelligence: The platform continued to combine order state, calculated times, driver availability, geospatial data, and configurable business rules. Smart Doubles and Triples could recommend combining multiple orders into a single driver trip when geography, timing, and operating conditions made it practical.
• Connected platform: As the broader OPD ecosystem matured, Restaurant Operations connected with centralized configuration and deployment capabilities, guest-facing order tracking, and reusable last-mile delivery services while retaining local execution for critical restaurant workflows.
• Proven when the operating model mattered most: By 2020, four years of investment had produced a mature platform deployed across hundreds of restaurants, with established processes for takeout, delivery, dispatch, and fleet management. When COVID-19 restrictions closed or severely limited dining rooms, the company already had the technology, processes, and restaurant experience needed to continue serving guests outside the dining room.
• Growth of a major revenue channel: Off-premises dining ultimately grew to nearly 30% of company sales, turning a capability originally built to support an emerging channel into a significant part of the business.