Take a catering order with headcount and delivery details in one place

Route each catering order to the kitchen

The field table below groups information in the sequence that a kitchen team uses it. Menu selection establishes what the customer expects to receive. Headcount gives the team the scale of preparation. The requested delivery time gives the reviewer a starting point for production and delivery planning.

Keep those three decisions separate in your application. A menu choice describes the requested food, not the final bill. A guest count supports preparation, but it does not settle portion sizes or dietary substitutions. A delivery time is a request until someone checks the kitchen schedule and transport arrangements.

That distinction prevents an intake form from becoming a promise. The form does not calculate pricing or check kitchen capacity for a given slot, so someone still confirms the order by hand. Use the submission as a complete review record, then let a staff member confirm the price, availability, and final delivery plan.

Treat the requested delivery time as operational input. A kitchen may need preparation time before the driver can leave. A venue may impose an arrival window. A large order may require a different delivery arrangement than a smaller office lunch. The submission gives the reviewer the facts needed to ask the next question without reopening the basic order details.

The settings block is useful when the business has a repeatable variation in its catering service. For drop-off-only catering with no on-site staff, drop serving_staff. This removes a question that the customer cannot answer meaningfully and keeps the review focused on preparation and delivery.

Add budget_per_head when customers need to state their budget before a menu is proposed. That value can guide a sales or kitchen review, especially when menu items are only an initial preference. Do not treat a customer-entered budget as an agreed quote. A staff member still needs to account for minimum orders, special requests, delivery, and taxes under the business rules.

Dietary requirements deserve an explicit review step after the order arrives. Menu items and guest numbers rarely communicate allergies, vegetarian needs, or cross-contact concerns by themselves. Make the reviewer read the submitted requirements alongside the chosen menu. Record the confirmation in the application workflow so the kitchen and customer have the same understanding.

Use the submission dashboard as the intake record, then create the next internal action from it. A staff member might create a preparation task after accepting the order. Another team member might contact the customer when the delivery time needs adjustment. Keep the original submission available so staff can resolve a question without copying details between messages.

FilaForms emits FormSubmitted after someone submits this template. Save the listener below as app/Listeners/NotifyKitchenOfCateringOrder.php. It reads the menu items, guest count, and requested delivery time from the stored submission, then records the order for the kitchen workflow.

<?php

namespace App\Listeners;

use FilaForms\Core\Events\FormSubmitted;
use Illuminate\Support\Facades\Log;

final class NotifyKitchenOfCateringOrder
{
    public function handle(FormSubmitted $event): void
    {
        $data = $event->submission->data;

        Log::channel('daily')->notice('Catering order requires kitchen review', [
            'form_id' => $event->form->getKey(),
            'menu_items' => $data['menu_items'] ?? null,
            'guests' => $data['guests'] ?? null,
            'delivery_time' => $data['delivery_time'] ?? null,
        ]);
    }
}

Laravel 12 discovers listeners in app/Listeners automatically. Replace the logging destination with the internal notification channel your kitchen already uses. The listener should send the submitted facts to that channel. Pricing and capacity decisions belong in the services or staff workflow that can make those commitments.

Choose this template when the application needs to capture a catering request before it becomes an accepted order. It suits a restaurant site that needs intake without introducing a full ordering system. A Laravel form builder for Filament keeps the order record alongside the rest of the application. See the FilaForms form features for submission review, notifications, and conditional follow-up questions.

The template is also a useful boundary between sales intake and kitchen work. Sales can review the request when the proposed menu needs discussion. The kitchen can assess whether it can fulfil the request after the menu, guest count, delivery time, and dietary needs are visible together. Neither team has to infer the original request from a partial email thread.

Avoid using this template as an automatic booking mechanism. It captures the information needed to assess an order. It cannot reserve production time or establish a final price. That limitation is deliberate because those decisions depend on current capacity and the catering business's own operating rules.