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
| Question | Answer |
|---|---|
| Shape | Dashboard with reporting for the owner; calculator flow for clients |
| Audience | Solo restaurant/catering business owner |
| Core loop | Client builds menu → sees live cost → submits inquiry → owner reviews and follows up |
| Success metric | 10 client submissions reviewed per week by day 30 |
---
The core loop
- A prospective client lands on the public catering page and opens the menu builder.
- They select dishes, adjust quantities, choose add-ons (service style, dietary requirements, headcount), and watch the estimated total update in real time.
- They fill in event details (date, location, guest count) and submit the inquiry with their contact information.
- The restaurant owner receives the inquiry on the dashboard, sees the full menu breakdown and cost estimate, and marks it as new.
- The owner moves the inquiry through statuses (New → In Discussion → Quoted → Booked / Lost) and logs notes or follow-up actions against it.
- 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_namemenu_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_modifierinquiries— id, owner_id, client_name, client_email, client_phone, event_date, location, headcount, status, estimated_total, created_atinquiry_line_items— id, inquiry_id, menu_item_id, option_id, quantity, unit_price, line_totalinquiry_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.