Before accepting inquiries through a website form, check four things: guests can complete it, mistakes are easy to correct, submissions reach the right person, and staff know what to do when something goes wrong. A form is ready only when the restaurant can both receive an inquiry and act on it.
Start with an agreed list of required fields and an intended inbox. Then run the checks below with someone who did not build the form. Record the result, fix failures, and repeat the affected checks before putting the link in front of guests.
1. Test required fields and clear error messages
Decide what the team needs to respond, not everything it might eventually want to know. For a catering inquiry, a name, a way to reply, and a description of the request may be essential. A guest count or event date may be useful, but consider whether a guest who is still exploring options can provide them.
Ask the person who handles inquiries to define the minimum information. The website provider or person managing the site should explain which fields can be changed and how errors appear. The owner should approve the final list and identify who can update it later.
For a hypothetical catering form, suppose the team requires a name, email address, event date, and message. Phone number and estimated guest count are optional. Use that form for the following examples; these are practice cases, not claims about any particular product.
- Leave each required field empty, one at a time. The form should identify the missing field and explain what to enter.
- Leave all optional fields empty. A valid inquiry should still be accepted.
- Enter an email without an address separator, then correct it. The error should be understandable, and the other answers should remain in place.
- Try a past event date and an uncertain future date. Decide in advance whether either should be allowed or prompt the guest to provide more detail.
- Write a short message and a longer one. If there is a length limit, make sure the guest can see or understand it before losing their text.
Check the confirmation as well. It should tell the guest that the form was submitted without promising a booking, quote, or response time the team cannot meet. If the page offers a response estimate, agree on that estimate with the staff who will answer.
2. Check delivery to the intended inbox
A success message on the page does not prove the restaurant received the details. Arrange a controlled end-to-end check using a test inbox the restaurant owns or has permission to use. Make sure the person monitoring it knows a test is coming. Use clearly marked practice details, not a real guest's information.
Submit a valid inquiry and compare the received message with what was entered. Check the name, reply address, date, message, and any optional fields. Confirm that the message goes to the agreed recipient, not just the person who built the site. Also inspect the spam or junk folder and any rules that move incoming mail.
Next, have the intended staff member open the message and prepare a response. Check that the guest's reply address is visible and can be used correctly. For practice, address a draft only to a controlled test address; do not send a message to an actual guest. If the form stores inquiries in a dashboard instead of, or as well as, sending email, ask the provider where staff should look and who has access.
One shared inbox can make coverage easier when an employee is off. It also needs an owner: decide who checks it during each service period and who covers days off. A message sent to several people may get faster attention, but can also produce duplicate replies unless someone claims it.
Test what happens if delivery fails where the provider offers a safe way to do so. For example, ask the provider to simulate an unavailable destination rather than changing a live inbox without a recovery plan. Find out whether staff see an error, whether a submission is retained, and how it can be recovered. Do not assume a visible confirmation means the inquiry is safely stored.
3. Test mobile and keyboard use
Many guests will open the form while making plans on a phone. Check it on at least one phone and one larger screen, using the browsers your team can reasonably access. A small set of checks will not cover every device, but it can reveal problems that make a form hard to finish.
On the phone, read every label without zooming or scrolling sideways. Tap each field and make sure the keyboard does not hide the next instruction or the submit button. Check that the date field is usable and that an error can be found and corrected. Rotate the screen if the site supports both orientations. After submission, confirm that the success message is visible without hunting for it.
Then use a keyboard instead of a mouse. Start at the top of the page and use Tab to move through the form. The focus should be visible, the order should make sense, and you should be able to reach and operate the submit button. Trigger an error and check whether you can find the problem and return to the right field without starting over.
Ask someone unfamiliar with the form to complete the same task without coaching. Notice where they pause or misunderstand a label. If they cannot tell whether an event date means the desired date or the date of the inquiry, rewrite the label and test it again. For more guidance on choosing a site setup that your team can maintain, see the restaurant website builder comparison.
4. Use an acceptance matrix and plan for exceptions
Give each check an owner and record pass or fail alongside the date, device, and any fix needed. The matrix below sets a practical minimum for the hypothetical catering form. A failure means the form is not ready for public inquiries until the issue is fixed and the relevant check passes again.
| Check | Practice action | Pass when | Owner |
|---|---|---|---|
| Required fields | Omit the email; complete the other required fields | The form identifies the email field and keeps the other answers | Site manager |
| Successful delivery | Submit valid practice details to a controlled inbox | The intended recipient receives the complete details | Inbox owner |
| Phone and keyboard | Complete the form on a phone; navigate it separately with a keyboard | Labels, controls, errors, and confirmation can be found and used | Independent tester |
| Duplicate or missing inquiry | Use practice records to walk through both cases | Staff can identify the case, assign an owner, and record the next action | Inquiry lead |
For duplicates, agree how staff will compare the name, contact details, event date, and message before replying. Two similar inquiries may be separate requests, so do not delete one solely because the names match. Assign one person to check and respond, and note the outcome where the team tracks inquiries.
For a suspected missing submission, decide who checks the inbox, spam folder, and any available submission history. Ask the provider how to investigate and recover a failed delivery, including what information is needed to locate it. Offer guests another contact method on the site so they have a way to reach the restaurant if the form does not work. Do not tell a guest their request was received unless staff can verify it.
Keep simulation and live checks separate. Practice exception handling with invented records and controlled accounts. A simulation should not charge a card, send a guest message, or dispatch a courier. Once the form is public, monitor real inquiries during an initial service period, assign coverage, and review any reported problems promptly. A live pilot involves actual guests and requires the normal response process; it is not a substitute for the safe checks above.
Recheck the form after changes to fields, routing, the site, or the domain. Make sure the restaurant can reach the person who controls those settings; the domain ownership guide covers a related part of that handoff.
Next step: Run the matrix on your current form and assign an owner to every failure. If you are considering a new restaurant website, ask Fleksa about current US availability and how your inquiry form would be set up, delivered, and managed.
Frequently asked questions
How do I know a form submission reached the restaurant?
Send a clearly marked practice inquiry to a controlled inbox and have the intended recipient confirm that all entered details arrived. Check the actual destination and spam folder, not just the website's success message.
Which catering inquiry fields should be required?
Require only what your team needs to understand and answer the request. Ask the inquiry lead to approve the list, and let guests leave less essential details optional when that fits your process.
What should staff do if an inquiry appears twice?
Compare the contact details, event date, and message before deciding it is a duplicate. Assign one person to handle the response and record the decision so another employee does not reply again.
