THE SHORT ANSWER
Send a clearly marked test through your own site using details you control. Follow it through the inbox or system your team actually uses. Record what worked and where it stopped. A confirmation screen is not the same as a verified handoff.
Tell the person who receives inquiries
Choose the form customers use for an ordinary inquiry. A quote form and a booking tool may go to different places. Testing one route does not establish that the others work.
Tell the person handling messages that a test is coming. Use an email address you control and make the test obvious. Do not enter real customer details, make a pretend payment or occupy an appointment somebody else needs.
Keep a private note of the page address, device and time. That gives your developer a specific submission to investigate if something goes wrong. A screenshot can help, but remove private information before sharing it outside the people doing the test.
Read the form as a new customer
Open the public page on your phone. Read the labels without relying on the answers you already know about the business. Check whether the form explains what is required and any unusual format it expects.
W3C guidance recommends identifying required inputs and useful format instructions. It also explains that disappearing placeholder text is not a replacement for a label. These are details to check, not a reason to assume the whole form needs replacing.
Notice anything that feels unnecessary for starting this particular conversation. Ask the person who handles inquiries why that field exists before removing it. A field may support a real business process that is not obvious from the page.
Press Send and record what happens
Write a simple test message and submit it once. Note whether you see a confirmation, an unexplained reload or instructions to correct something. Save the actual wording instead of reporting that the page just felt broken.
W3C recommends understandable feedback for successful and unsuccessful submissions. Ask whether the confirmation describes what the system actually completed. It should not promise an appointment or quote if it only recorded a request.
Read any response time on the page too. That promise needs to come from the person responsible for answering. Do not copy an impressive deadline from another website and assume your team can meet it.
Find the message inside the business
Now check the destination with the responsible person. It could be an email inbox, a saved submission list or a customer management system. Look at the setup the business actually uses rather than assuming every form works the same way.
Find the test and compare it with what you entered. Check that the information needed for a useful reply arrived. If it is missing, ask the developer to trace that particular submission. A missing email alone does not identify whether the form, routing or mailbox is the cause.
Use the normal reply process and send a short response to your controlled address. Confirm that it arrives and that the sender details make sense. Also establish who handles the inquiry when the usual person is away. That part may be an office process rather than a website repair.
Give the repair a specific target
Write the finding as an observation. For example: the page confirmed receipt, but the test was not visible in the intended inbox. That is an example of useful reporting, not a diagnosis of your site. Add the actual page and time to your private note.
Ask for an explanation of the proposed repair and how it will be tested. After the change, repeat the same route. One successful test confirms that test, not every future inquiry, so keep the procedure for the next form or mailbox change.
For a website project with Your Page, include the troublesome page and observed behavior in the brief. Leave out passwords and private customer messages. We need to understand the route that failed, not collect the information it was carrying.