The moment a visitor submits a request, the website becomes part of an operating process. Someone must receive the information, understand the need and decide what happens next. Designing that process alongside the interface prevents an attractive form from becoming an unattended queue.

At a glance

  • Assign an owner to each request type.
  • Confirm only the action that actually occurred.
  • Test submission, receipt and reviewer access together.

Name the request and its owner

Decide what the form is for. A general inquiry, a procurement brief, a service booking and a confidential source submission have different needs. Combining them without clear routing asks the visitor to solve an internal organizational problem.

For each request type, identify the person or role that reviews it. Define what information is needed for that first review and remove fields that have no immediate purpose. If the request belongs to another business or editorial channel, make that path clear before the visitor submits.

Make the confirmation match the actual action

A confirmation should describe what the system has done. Preparing an email in a visitor’s own application differs from saving a submission to an inbox. Receiving a request differs from accepting an engagement or confirming a booking.

These distinctions should appear at the point where they help the visitor act. A clear button label, a concise explanation and an accurate receipt do more useful work than a long disclaimer elsewhere. If the process provides a reference, explain how the visitor can use it in follow-up.

Design for the incomplete or interrupted request

List the ordinary ways the process can fail: missing information, an unsupported attachment, a lost connection or uncertainty about whether submission succeeded. Decide how the visitor can recover without starting the entire conversation again.

The implementation should be tested against its stated behavior. A working upload control alone does not prove the documents can be retrieved by the intended reviewer. Likewise, a success message is meaningful only when it follows the action it claims has occurred. Testing the full path is part of delivering the feature.

Give the reviewer a usable handoff

Organize the received information around the decision the reviewer needs to make. Contact details, scope, deadline and supporting documents should be easy to distinguish. Define statuses that mean something operationally, such as awaiting review, needing clarification or closed.

Agree how access is granted and how information is removed when no longer needed. The operating team should understand where requests live and whether notifications exist. An inbox that depends on manual review needs a named review routine; the interface should not imply an automated response that has not been configured.

Test the promise from both sides

Review the journey as a visitor and as the recipient. Can the visitor understand the next step? Can the recipient act on the information? Are alternative contact options available when the primary route is unsuitable?

At Gaskin, general inquiries and RFPs save to a private website inbox. The RFP route also accepts PDF documents. Both provide a reference after storage, with email status handled separately. The broader lesson is to make the customer-facing promise and the operating process describe the same reality.

Working checklist

  • Request purpose and routing
  • Required information and attachment limits
  • Accurate receipt and recovery messages
  • Reviewer access and review routine
  • Retention and alternative contact process