eode docs
Tutorials

Turn a losing week into a plan

A full worked example: hand eode a restaurant's books, get a weekly plan, and check the result.

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

The whole thing takes about five minutes.

The situation

A neighborhood restaurant closed last week at −$2,120, with roughly two weeks of cash left. 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.

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. You don't need it cleaned up or reshaped.

Step 2 — Describe the decision and attach the file

Open the RIA console, click the paperclip, attach the CSV, then write what you're deciding. Be specific about the levers and the physics — this description is what the model gets built from:

I run a neighborhood restaurant. Author and solve an optimization model that picks each week's plan to maximize weekly profit. Weekly decisions: days open, hours per day, price for each of four dishes (House Burger, Garden Salad, Pasta of the Day, Chef's Special), perishable food order (spoils if unused), dry-goods order (carries over), cooks, servers, hourly wage, and marketing spend. Each customer uses about 1 unit of fresh food ($4.20) and 0.6 unit of dry goods ($1.40); unused fresh food spoils. A cook plates ~9 covers/hour, a server handles ~13/hour. Labor = (cooks + servers) × wage × days × hours. Rent $1,500/week plus utilities. About 380 potential diners a week; prices are elastic around Burger $14, Salad $11, Pasta $16, Special $28; marketing has diminishing returns past ~$500. Attached are my last few weeks of books. Give me the single best weekly plan.

Press Enter (or click the Send arrow).

Don't use the sparkle Fast author button here. It's text-only — it ignores and clears attachments, so your CSV would be silently dropped. Send bundles the file with the message.

Step 3 — Watch it build

A description this complete goes straight to a build, about 30 seconds. eode authors the model from your words and your books, solves it, sets up KPIs (weekly profit, meals served, kitchen utilization), and scans external market factors relevant to your business — for a restaurant, things like food-away-from-home inflation and input prices.

If anything essential is missing, RIA asks one clarifying question instead of guessing. Answer it in a line and the build continues.

Step 4 — Ask for the plan in plain numbers

When it returns, ask in the same conversation:

Give me the exact weekly plan as plain numbers.

For this restaurant the answer comes back lean and higher-priced: fewer open hours, one cook and one server, prices up around 10%, and a food order right-sized to the covers the plan actually expects — turning a −$2,120 week green.

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

If RIA flags a caveat about its own model, take it seriously: it's telling you which part of the answer rests on a thin assumption. That's the part to firm up with better data.

Step 5 — Pressure-test before you commit

One plan isn't a decision. Branch what-ifs from it:

  • "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 2–5 of them 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, let eode build and prove the model, read the binding constraints, then branch what-ifs before committing. Nothing about it required knowing optimization.

Next

On this page