MindPalaceX · The Workshop
The Idea Wall →

On the Idea Wall · ▲ 0 votes

CaterDesk — the spec

A web-based catering inquiry tool for a family-owned restaurant that replaces scattered emails with a structured self-serve flow. Prospective clients build their own menu, see a live cost estimate, and submit it directly to the restaurant. The owner gets a dashboard of every inquiry, its status, and follow-up activity — nothing goes cold, nothing gets lost.

---

Decisions locked

QuestionAnswer
ShapeDashboard with reporting for the owner; calculator flow for clients
AudienceSolo restaurant/catering business owner
Core loopClient builds menu → sees live cost → submits inquiry → owner reviews and follows up
Success metric10 client submissions reviewed per week by day 30

---

The core loop

  1. A prospective client lands on the public catering page and opens the menu builder.
  2. They select dishes, adjust quantities, choose add-ons (service style, dietary requirements, headcount), and watch the estimated total update in real time.
  3. They fill in event details (date, location, guest count) and submit the inquiry with their contact information.
  4. The restaurant owner receives the inquiry on the dashboard, sees the full menu breakdown and cost estimate, and marks it as new.
  5. The owner moves the inquiry through statuses (New → In Discussion → Quoted → Booked / Lost) and logs notes or follow-up actions against it.
  6. Weekly summary view shows conversion rate across the pipeline so the owner knows which inquiries to prioritise.

---

v1 scope

Menu Builder (client-facing) — A step-by-step selector where clients choose dishes from predefined categories, set quantities, and pick available options. Lives on the public inquiry page; no login required for the client.

Live Cost Estimator — Calculates and displays a running subtotal as selections change, based on per-head or per-item pricing the owner configures. Shown inline within the menu builder.

Inquiry Submission Form — Captures event date, location, headcount, and client contact details alongside the finalised menu snapshot. Submits to the owner's dashboard and sends a confirmation email to the client.

Owner Dashboard — Lists all incoming inquiries with status, event date, estimated value, and last-action date. Allows the owner to filter by status and open any inquiry for full detail. Requires owner login.

Inquiry Detail & Status Tracking — Shows the full menu selection, cost breakdown, and client info for a single inquiry. Owner can update status, add internal notes, and log follow-up actions — the audit trail that prevents inquiries going cold.

Reporting Summary — A simple metrics panel showing total inquiries, status breakdown, and estimated pipeline value for a rolling period. Gives the owner a weekly read on what is working.

---

Deliberately later

  • Client accounts and saved quotes — clients re-visiting their quote is a repeat-visit behaviour that only becomes relevant once inquiry volume is proven; adds auth complexity too early.
  • Online deposit or payment collection — payment flow requires compliance and trust-building that comes after the booking relationship is established, not before.
  • Automated follow-up emails / reminders — valuable once the owner has validated which cadence works; wrong to automate a process not yet understood.
  • Calendar or scheduling integration — availability management is a second-order problem; v1 confirms whether digital inquiries convert before solving scheduling.
  • Multi-user / staff access — the audience is a solo owner; team permissions add surface area with no immediate beneficiary.

---

Data model sketch

  • owners — id, name, email, hashed_password, restaurant_name
  • menu_items — id, owner_id, category, name, description, unit_type (per_head / per_item), base_price, available (bool)
  • menu_item_options — id, menu_item_id, option_label, price_modifier
  • inquiries — id, owner_id, client_name, client_email, client_phone, event_date, location, headcount, status, estimated_total, created_at
  • inquiry_line_items — id, inquiry_id, menu_item_id, option_id, quantity, unit_price, line_total
  • inquiry_notes — id, inquiry_id, body, created_at (owner-side audit log)
  • status_history — id, inquiry_id, old_status, new_status, changed_at

---

Screens

  • Public menu builder — client-facing step flow: category browse → item selection → options → event details → submit
  • Confirmation page — post-submission acknowledgement for the client with a summary of what was sent
  • Owner login — single credential gate to the dashboard
  • Inquiry dashboard — filterable list of all inquiries with status, value, and date columns
  • Inquiry detail — full breakdown of one inquiry; status controls, notes, and history
  • Menu management — owner configures items, categories, pricing, and toggles availability
  • Reporting summary — pipeline metrics panel with status counts and estimated value totals

---

How to use this document

  • Bring it into Mind Palace, where the guided platform and its AI coach pick up from exactly this document and build the product with you step by step.
  • Hand it to a developer as the complete v1 brief — scope, data model, and screen list are all here.
  • Keep it as the single source of truth while you build, so every decision can be checked against what was agreed.

This is Alexia's. Build yours.

A spec like this is step 3 of Mind Palace's nine — the other six take a weekend: working software, a real offer, first customers.

Want to build this with Alexia?

Tell us who you are and we'll broker the introduction — their contact details stay private until they say yes.