Franchise analytics for operators who run the restaurants, not sell the franchises

It is 7:40 on a Monday. Somebody in your office has a workbook open with one tab per store, and they are pasting last week's numbers out of four different exports so that by ten o'clock you can look at one sheet. By the time you look at it, the week it describes is over, two of the stores have already been staffed for the week ahead, and the one number you actually wanted — food cost variance by store — is not on it because the counts came in late.

That is the job. Everything below is about that job.

“Franchise analytics” means two completely different things

Search the term and most of what comes back is written for someone deciding whether to buy a franchise. Unit economics, average unit volume by brand, initial investment, Item 19 comparisons, payback period. That is franchise development analytics, and it is aimed at a buyer who does not own a restaurant yet.

This page is about the other meaning.

Franchise analytics, for an operator, is reporting and forecasting across a group of restaurants you already own or operate: daily sales, labor, food cost, third-party delivery, a consolidated P&L and a forward look, pulled from the systems you already run and delivered on a schedule.

The unit of analysis is the store-day and the store-period, not the deal. If you run 20 to 150 locations, that second meaning is the one you were searching for. The rest of this page assumes it.

What you are actually trying to answer

Strip out the software talk and there are about six questions a multi-unit operator needs answered on a repeating clock. They do not change much between brands.

Yesterday. What did each store do, against last year and against forecast, and which three stores are the problem this morning. Needed before your district managers get in the car, not at ten.

Labor, while it can still be fixed. Where did scheduled hours and actual hours separate, at which store, on which day, in which daypart. Wednesday is too late for Saturday.

Food cost, at the store that is drifting. Not the group number — the group number is always fine. One store is three points off, and you want to know which one before the period closes rather than three weeks after.

The P&L, in one shape, for every location. Same line order, same subcategories, same period boundaries, so that two stores can be put next to each other without someone reworking a mapping.

Next week. A sales number per store per day that is good enough to schedule against. Not a plan number. A forecast.

The schedule, before it goes out. Whether what your GM built matches the sales you expect, in the half-hour bands where it matters, while there is still time to edit it.

Any tool worth looking at should answer all six. Most answer two or three well and hand you a dashboard for the rest.

Why the spreadsheet holds, and then stops holding

Almost every group of this size runs on spreadsheets, and for a long time that is the right answer. A workbook is free, it is exactly the shape you want, and the person maintaining it understands the business.

It breaks in a specific and predictable way, and it is worth naming so you can tell whether you are there yet.

It breaks on people, not on volume. The workbook is not fragile because of the number of rows. It is fragile because one person knows which tab feeds which, and when that person is on holiday or leaves, the group loses its reporting. If you cannot name a second person who could rebuild the Monday pack from scratch, you are already exposed.

It breaks on lag. Manual assembly means the report describes a week that has ended. Reporting that arrives after the decision is history, not analytics. The test is not accuracy — it is whether anyone changed a schedule or made a call because of it.

It breaks silently. A store that was offline for a day reports zero sales. A naive average happily includes that zero and tells you the group is down. Nothing in the workbook flags it. You find out when a GM calls, annoyed, about a number he knows is wrong.

It breaks on joins. Employee names are the classic one. The same person is “Rob Alvarez” in one system, “Robert Alvarez” in another and “Alvarez, Robert” in a third. Join on name and you either duplicate their hours or drop them. Nobody notices until an overtime number looks impossible.

None of that means stop using spreadsheets. It means the spreadsheet should be the thing you build an ad hoc analysis in, not the thing that produces the same five reports every week for a group of forty restaurants.

The four data sets that have to line up

Everything an operator wants comes from four places. The work is not in getting the data. It is in making the four agree with each other.

Sales. Comes off the point of sale, at whatever grain the system will give you: net sales, gross sales, discounts, comps, voids, taxes, transaction counts, daypart splits. The first trap is that “sales” is at least four different numbers, and different reports inside the same system will disagree unless you fix which one you mean. Pick net sales after discounts and comps, write the definition down, and hold every report to it.

Labor. Comes from payroll and from the scheduling system, and those are two different truths. Scheduled hours are a plan. Actual hours are punches. Paid hours are punches after edits, approvals and rounding. Report against the wrong one and you will spend a quarter arguing with your COO about whose number is right.

The second trap is overtime: an hourly employee who works 28 hours at one store and 17 at another is under 40 in both systems and over 40 in reality. If your reporting is per-store, you will not see it until payroll runs. The third trap is salaried managers, who should not be carrying overtime at all and will if someone maps them wrong.

Purchases and inventory. Comes off invoices and counts. This is the messiest of the four and the one where most groups have the least confidence. Invoices get posted to the wrong period. Credits show up two weeks after the return. A count taken Sunday night and a count taken Monday at ten produce different usage for the same period. Theoretical usage depends on recipes, and recipes drift as GMs substitute. Every food cost variance number you have ever looked at is a mixture of real variance and this.

Third-party delivery. Comes from the delivery platforms, and the number they show you and the number that hits your bank are not the same number. Gross order value, commission, promo funding you agreed to, promo funding you did not, refunds and adjustments that land in a later payout, marketplace facilitator tax handled differently by platform and by state. If your P&L takes delivery sales at gross and your bank takes them at net, you have a reconciliation problem that grows every period.

The reason this section is longer than the software section is that this is where the actual work is. Anyone can connect. Making four systems agree on what a week is, what a store is, and who an employee is — that is the product.

The calendar problem, which nobody mentions until close

Most restaurant groups do not run on months. They run on 13 periods of four weeks, or on 4-4-5, so that every period contains the same number of Fridays and Saturdays and period-over-period comparisons mean something.

Almost every general-purpose reporting tool runs on calendar months. So does most accounting software out of the box. So the group ends up with two calendars — the one the P&L uses and the one the sales reports use — and then someone spends the first three days of every period reconciling them.

If you take one thing from this page and never buy anything: decide your period calendar once, write down the exact start and end date of every period for the next two years, and make every report use it. Sales, labor, food cost, P&L, bonus calculations, all of it.

The single most common source of “these two reports disagree” in a multi-unit group is two reports using two different date ranges and both being correct.

A spec you can hold any vendor to

This is the part that is useful whether or not you ever talk to us. If you are evaluating anything in this category, these are the questions that separate a real answer from a demo.

1. What time does yesterday's number land, and what happens when it does not? Ask for the hour, not “overnight”. Then ask what happens when the source system is down for maintenance at 5am. The right answer describes a retry and an alert. The wrong answer is that the report goes out with a hole in it and nobody knows.
2. Does it push, or do I log in? Every tool in this category will show you a dashboard. Very few will put the right four numbers in front of a district manager at 6:30 without him going and looking. Reporting that requires a login gets used for two weeks. Ask specifically whether reports are emailed or texted on a schedule, to a list you control, per role.
3. Where does labor cost come from? Schedule, punches or payroll. Make them say which. Then ask how overtime is calculated for an employee who works at two locations in the same week.
4. What is your period calendar? If the answer is “monthly” and you run 13 periods, you have found the end of the evaluation.
5. How does a store with no data appear? Blank, zero, or flagged. Zero is the wrong answer and it is the common one.
6. Theoretical food cost: where does the recipe come from and who maintains it? If the answer is “you do”, that is honest and fine. If the answer is vague, the theoretical number will be decorative.
7. Show me a forecast, at store-day grain, and tell me its error rate. Anyone can show you a chart of last year. Ask what the average absolute percentage error is at the store-day level, and how holidays and closures are handled. A vendor who has measured it will tell you a number. A vendor who has not will talk about machine learning.
8. Can I get one P&L across all locations without changing how I do accounting? For most groups this is the deciding question. Replacing an accounting platform is a nine-month project with a bookkeeping team attached. Reporting on top of the accounting you already run is a different scale of decision entirely.
9. What does implementation actually mean, in days? Ask what has to happen on your side, what access is needed, and when the first complete period lands.
10. When it is wrong, who finds out first — you or me? The honest version of this answer involves monitoring and an alert. There is no data pipeline anywhere that does not break. There are only pipelines that tell you and pipelines that do not.

Where analytics stops and accounting starts

Worth being clear about, because buying the wrong one costs a year.

An accounting platform owns the ledger: invoices, AP, journal entries, the chart of accounts, the closed books. It is the system of record, and replacing it is a migration.

An analytics layer does not own the ledger. It reads from the systems that do, joins them, and produces the operating view — yesterday's sales, this week's labor, the store that is drifting on food cost, a P&L in the shape your operators read, the forecast you schedule against.

Groups get sold the first when they wanted the second, usually because the second was described as a feature of the first. The symptom is a nine-month implementation, a new set of processes for a bookkeeping team that was not the problem, and, at the end of it, a dashboard nobody in the field logs into.

If your books are fine and your reporting is late, you have a reporting problem.

How we approach it

MyFranchiseAnalytics is the second thing. It reads from the systems you already run, overnight, and delivers the operating view on a schedule.

It pulls rather than asks. Sales, labor, purchases and delivery data are collected overnight from the systems you already use. Which systems, and how, is a discovery conversation, because the answer depends on what you run and what your contracts allow. It is not a claim worth making in the abstract.

It pushes rather than waits. Daily sales and labor in the morning, food cost and variance on the period clock, a P&L pack at close, a forecast for next week, and a schedule review before the schedule goes out — to a recipient list you control, by role. There is a place to log in and look at everything, and most of the value arrives before anyone does.

It runs on your calendar. 13 periods, 4-4-5, or months if that is genuinely what you use. Set once, applied everywhere.

It says when it is broken. A store that did not report is flagged as missing, not counted as zero. A source system that was down produces an alert, not a quiet gap.

Onboarding is under a week from your first data feed to your first full period. That is the honest number and we are not going to dress it up. The week is mostly spent on the parts that are specific to you: your store list, your period calendar, your P&L line mapping, and who gets what.

If you want to see the shape of it rather than read about it, the walkthrough on the home page goes location by location, from the parking lot to the back office, and shows what lands where. There is API documentation if you have an analyst who wants the data somewhere else, and a changelog if you would rather see what has shipped than what is promised.

If you are still on the workbook

You are not behind. Most groups this size are, and the workbook is often better than what replaces it — right up until the week it is not.

The two things worth doing regardless: fix your period calendar, and write down your definition of net sales. Those two decisions cause more disagreement between reports than every software choice combined, and both are free.

When you do want the Monday pack to build itself, the useful conversation is not a demo. It is twenty minutes on what you run today, what your period calendar looks like, and which of the six questions above is actually costing you. Some of the time the answer is that you do not need us yet, and that is a fine outcome for a twenty-minute call.