← Back to Work
Case Study · Business, Financial & Operational Systems

Business Intelligence & Financial-Operational Systems for a Multi-Location Hospitality Business

A connected set of financial, operational, and analytical models built to bring structure and clarity to a growing hospitality operation spanning restaurant, catering, and event service lines.

Restaurant & food service Catering Events Multi-location
A note on the data shown here. The systems below were built for a real multi-location hospitality business. To protect the ownership and confidentiality of the underlying business data, the company name, exact figures, and identifying details have been generalized or altered โ€” the problems, approach, and analytical methods are represented accurately.

Financial Planning & Cost Control

Models built to give leadership a forward-looking, assumption-driven view of financial performance โ€” turning "should we do this?" and "where is margin leaking?" into structured, testable questions.

Cost of Goods Sold (COGS) Model

In active use
Problem Draft โ€” pending detail

With three distinct revenue lines โ€” restaurant, catering, and events โ€” each carrying different recipe costs and vendor pricing, leadership lacked a clear, consistent view of true food and beverage cost as a percentage of revenue by line and by location.

Approach Draft โ€” pending detail

Built a model to calculate theoretical COGS from recipe-level ingredient costs, compare it against actual purchasing and usage data, and surface variance so cost leakage could be caught early rather than discovered at month-end close.

How it works Draft โ€” pending detail
  • Recipe-level ingredient costing rolled up to a theoretical COGS % per revenue line
  • Actual vendor invoice costs compared against theoretical to flag variance
  • Breakout by location and by revenue stream (restaurant / catering / events) rather than one blended number
What was built

A spreadsheet-based COGS tracking model with a monthly variance report used in operational reviews.

Outcome Draft โ€” pending real figures

Gave leadership visibility into COGS variance by location and revenue line for the first time, surfacing where actual cost was drifting from recipe-based expectations.

Purchasing Cost-Saving System

In active use
Problem Draft โ€” pending detail

Purchasing decisions across multiple locations and vendors weren't being systematically compared, making it difficult to know whether the business was consistently getting the best available pricing and terms.

Approach Draft โ€” pending detail

Built a system to standardize how purchasing costs are compared across vendors and locations, surfacing savings opportunities and inconsistent pricing on the same items.

How it works Draft โ€” pending detail
  • Vendor price comparison across shared/common items purchased at multiple locations
  • Flags locations paying above the best available negotiated price for the same item
  • Consolidation recommendations where volume could be combined across locations for better terms
What was built

A spreadsheet-based comparison model with a recurring savings-opportunity report.

Outcome Draft โ€” pending real figures

Identified specific vendor and item-level pricing inconsistencies across locations, informing renegotiation and consolidation decisions.

Inventory & Pricing Intelligence

Models built to keep pace with a business where input costs and stock levels shift constantly across multiple locations and revenue streams.

Inventory Analytics

In active use
Problem Draft โ€” pending detail

Inventory levels across multiple locations weren't consistently visible, making it hard to tell overstock, waste, and stockout risk apart from normal operating variation.

Approach Draft โ€” pending detail

Built an analytical view of inventory usage and par levels by location, so patterns in waste and shortage could be caught and addressed rather than treated as one-off incidents.

How it works Draft โ€” pending detail
  • Usage trend tracking by item and location against set par levels
  • Waste and shrinkage flagged where usage doesn't reconcile with sales-driven demand
  • Location-level comparison to separate one-off issues from systemic ones
What was built

A spreadsheet-based inventory tracking and analysis model with a recurring waste/variance summary.

Outcome Draft โ€” pending real figures

Improved visibility into where waste and overstock were concentrated by location, supporting adjustments to ordering and par levels.

Price Tracking System

In active use
Problem Draft โ€” pending detail

Vendor pricing on key food and beverage inputs shifted frequently and wasn't consistently tracked, creating a risk that menu pricing would fall out of step with actual cost and quietly erode margin.

Approach Draft โ€” pending detail

Built a system to track vendor price movement over time on key inputs and flag when changes were significant enough to warrant a menu pricing review.

How it works Draft โ€” pending detail
  • Ongoing tracking of vendor price changes on core ingredients over time
  • Threshold-based alerts when a price move is large enough to affect margin materially
  • Direct link from price movement to affected menu items, to make pricing review decisions faster
What was built

A spreadsheet-based price tracking model feeding a recurring vendor price movement report.

Outcome Draft โ€” pending real figures

Gave leadership earlier visibility into cost pressure on key menu items, supporting more timely pricing decisions.

Workforce Optimization

A model built to align labor with actual demand across dayparts, locations, and service lines โ€” the largest controllable cost in a hospitality operation.

Staff Scheduling Model

In active use
Problem Draft โ€” pending detail

Labor scheduling across dayparts and locations wasn't closely tied to actual demand patterns, creating a mix of overstaffing during slow periods and understaffing during peak periods.

Approach Draft โ€” pending detail

Built a demand-based scheduling model that ties staffing levels to sales and traffic forecasts by daypart, rather than scheduling off a fixed, historical template.

How it works Draft โ€” pending detail
  • Historical sales and traffic patterns by daypart and day-of-week as the demand baseline
  • Labor hours recommended per shift based on projected demand, not a static template
  • Labor cost as a percentage of projected sales tracked against target by location
What was built

A spreadsheet-based scheduling and labor-cost model used to guide weekly schedule building.

Outcome Draft โ€” pending real figures

Improved alignment between scheduled labor hours and actual demand, supporting better labor cost management across dayparts.

Status: The fields marked "Draft" above are my best-guess reconstructions based on the problem each model solves โ€” written so the page has real structure to react to. They still need to be checked against what was actually built (inputs, methods, and any measurable outcomes) before this goes live.