One “Contact us” form may have served a small team well. As sales, support, billing, and partnerships become separate workflows, a shared inbox can make customers wait while staff forward messages. The solution is not necessarily four new forms. First identify what customers are trying to do and which team owns each answer.
Map the real request types
Review a sample of recent contact messages with personal details removed. Group them by purpose and note where each one actually ended up. Which requests were forwarded more than once? Which were answered by the wrong team? Which need account verification and should never be handled through a public web form? These observations determine the page structure.
Name the response owner for each route. “Sales” may be clear internally but less clear to a current customer who needs help changing an order. Use customer language such as “Ask about a new project,” “Help with an existing order,” or “Billing question.” State hours or response windows only if those are maintained operationally.
Keep the choice simple
If there are three distinct tasks, three visible paths may be easier than a long dropdown. A small business may only need one form with a required “What do you need?” field and clear triage rules. Do not ask users to know your organization chart. Provide a general route for requests that do not fit the listed options, so someone is not blocked by uncertainty.
If a form creates a ticket or sends an email, check both parts. A browser success message confirms only the submission step. Google Workspace’s form-mail troubleshooting shows that notification delivery is a separate concern. Test where the message is stored, who is notified, and what happens when the recipient is absent.
Check the customer’s next message
The confirmation should say which team will respond and through what channel. Avoid promising “within one hour” if the queue has no coverage after hours. A current customer with a time-sensitive order may need a different route from a new prospect. If a case number is generated, show it in the confirmation and email.
Run a mobile test for each route. Ask an outsider to find how they would reach support without scrolling through a sales pitch. Submit a test request to every path and verify the correct destination. Recheck after staff or mailbox changes.
ARCHV can scope the contact-page structure, labels, and approved form checks. CRM routing, helpdesk integration, email deliverability, and staffing policy require separate work. Request a website estimate with your current contact page and a list of actual request types and owners.
Keep a small log of misrouted test messages after changes to mailboxes or teams. If a route starts forwarding through several people, revisit the page labels and the destination rule together. The website should describe the contact process customers will actually experience.
For account-sensitive requests, make clear what the public form can and cannot handle. A billing or privacy issue may require identity verification through a secure support process. The website can route the customer to that process without collecting payment details or documents in a general-purpose inbox.