Turn a losing week into a plan

This walkthrough takes a small business that is losing money and ends with a specific weekly plan you can argue with. It uses a restaurant because the shape is familiar — the same steps work for a plant, a network, or a portfolio.

The situation

A neighborhood restaurant closed last week at −$2,120, with $6,000 in the bank. The levers are ordinary ones: days open, hours per day, prices for four dishes, how much perishable food to order (it spoils), dry goods (they carry over), how many cooks and servers, what to pay them, and how much to spend on marketing. Every combination interacts. There are too many to try by hand.

The physics are known, roughly, the way an owner knows them:

Step 1 — Get the numbers into one file

Export the books as CSV. Anything that records what you did and what happened works: weekly sales, costs, staffing, hours. It does not need cleaning up or reshaping.

Step 2 — Start the model and attach the books

In the left rail, click New Model, then Next past the intro. Pick Basic and name the model — Canyons Restaurant, weekly plan.

On Describe your problem, open Upload or select relevant datasources and click Upload new datasets and attach them to this model. The Import Data window opens; choose CSV / TSV, drop the file, keep everything selected, then Import data → and Attach to this model →. Your books are now a dataset — one you can reuse on the next model without uploading again.

Step 3 — Say what you are deciding

Still on the hub, fill the other two rows. Be specific about the levers and the physics: this is what the model gets built from.

Describe your goals → What to optimize: Maximize, then weekly profit. Hard limits:

a cook plates about 9 covers an hour and a server handles about 13, there are only about 380 potential diners a week, and rent is $1,500 a week whatever we do.

Describe your business:

I run a neighborhood restaurant and I am picking each week's plan. The weekly decisions are days open, hours per day, the price of each of four dishes (House Burger, Garden Salad, Pasta of the Day, Chef's Special), how much perishable food to order (it spoils if unused), how much dry goods to order (they carry over), how many cooks and servers to roster, the hourly wage, and marketing spend. Each customer uses about 1 unit of fresh food at $4.20 and 0.6 unit of dry goods at $1.40. Labor is (cooks + servers) × wage × days × hours. Prices are elastic around Burger $14, Salad $11, Pasta $16, Special $28, and marketing has diminishing returns past about $500. Attached are my last few weeks of books.

Finish, then Next.

Step 4 — Check the reading, then answer the questions

Step 2 of the wizard is Clarify. Set the scrutiny dial under "How closely should I question this?" — on a decision with this much money in it, Intense ("Keeps asking, up to six rounds, until nothing is left to clarify.") is worth the extra minutes; Moderate is the default.

Because your books are attached, Clarify first shows how it read them, and nothing is designed until you agree:

• Your data, as I read it — Use it on the sales, cost and staffing tables; Set it aside on anything that is a summary rather than a record. Check that WHERE THE NAMES COME FROM found your four dishes as the products.
• The columns and the terms — settle any unit it could not read: covers or dollars, weekly or daily.
• What is missing — the books record what happened, not the physics. Where a gap asks for something your description already states — rent, throughput, market size — answer it Supplied: it is in... and say it is in the description. Use Assume it, with my consent only where you are content with its proposal.
• What you want to decide — your description is already in the box; sharpen it to the decision, for example Pick next week's opening hours, prices, order quantities, roster and marketing spend to maximize profit. Then Design on this reading.

See Building models for each screen.

The questions come one per screen, chipped REQUIRED or OPTIONAL, each with a Why this? that says why it is being asked. Expect the things a menu and a set of books do not record: whether the demand figure is an obligation or a forecast, how long the fresh food keeps, whether a dish can be dropped. Answer what you know and mark the rest Does not apply to this plan. Use ADD YOUR OWN for a rule the brief missed — a lease clause, a minimum roster.

Finish answering, then Next.

Step 5 — Confirm what it built

Step 3 opens on Building. When it lands, WHAT THE BUILD FOUND lists four readouts. On a model with your own data attached, two are the ones to read: Where your data lands (which of your columns it took, which it could not place, and where a stand-in value is still filling in for a number of yours) and Independent review (a separate pass over the built model against your brief — what it says is missing, and what it says was invented).

Next opens Check the design, every section on one page. Read each against the business you described — SCOPE should hold four dishes, not three, and RULES should read back your caps in plain English. Give each one Confirm, or Needs correcting with a note. With any note written, Next is Rebuild with these notes; when every section reads Confirmed, it is Accept the design.

Step 6 — Bind your books

Step 4, Load data, lists the tables the model asks for. Choose Load my own data, point each table at the dataset you imported, and let RIA propose the binding; where a column is misread, say so in Talk to RIA about this data — "The Region column is really the site name" — and Re-score with these changes. Review your datasources shows each table's match percentage, then Bind the data to the model and Accept and solve.

If the design did not draw up a table list, the step says so — "Nothing more to load" — and Next goes straight on.

Step 7 — Read the plan

Your baseline asks "Does this read like your business?" and gives you the objective, the result narrated in business language, and THE NUMBERS IT TRACKS — the KPIs this model will carry from here on.

Read the narrative and the KPI tiles before you act. The narrative names which limits are binding — that is what is actually capping the result.

If the read-back does not describe your restaurant, Needs correcting takes a note and Send back returns the model to Clarify with it on the record.

Step 8 — Pressure-test before you commit

One plan is not a decision. Go to Model Overview, open Scenarios, and branch what-ifs from Base in plain English:

• "What if fresh food costs rise 15%?"
• "What if I keep the current prices instead?"
• "What if I can only staff two people total?"

Each becomes a scenario with its own solve and deltas against Base. Compare a handful side by side, and use Verify on the one you plan to act on so you have an evidence record for the decision.

What to take from this

The pattern generalizes: describe the decision and its physics in plain English, attach whatever data you have, answer the questions, confirm the design section by section, bind your numbers, read the binding limits, then branch what-ifs before committing. Nothing about it required knowing optimization.

Next

• Building models — every screen of the five steps, and the advanced imports.
• Reading results — binding limits, KPI tracing, Verify.
• Workflows and runs — make this a repeatable weekly process.