From inquiry form to private project receipt

1. Keep the first request small

Our project inquiry asks for a name, email, project type, description, timing, and budget range. A company and existing website provide optional context. It does not ask for account passwords or payment-card information. The first interaction is a request to discuss work; it is not a checkout or a promise that a time slot has been reserved.

The browser checks required fields before sending. The description must contain at least 20 characters, which catches an empty or very brief request but cannot determine whether an idea is good. The backend must also validate the request: browser checks can be bypassed and are there to help the visitor, not to protect stored records.

1. The visitor describes the project and submits the form.
2. The form sends a request to the studio service and waits for its response.
3. The response must include a project reference and a valid private receipt link.
4. Only then does the page replace the form with a receipt and a way to open the project.

A useful acceptance check is therefore “the customer receives a reference and can return to the right request,” rather than simply “the Send button changes color.”

2. Treat a lost response as uncertain

A connection can fail after the service saved a request but before the browser received the reply. Telling the customer “nothing was saved” would be a guess. Our form instead says it could not confirm receipt and keeps the entered details on screen. Its timeout is 20 seconds; reaching that limit means the browser stopped waiting, not that the server necessarily stopped working.

For unchanged form details, the browser reuses the same request identifier on a retry. This gives the service a way to recognize the same attempt rather than treating every click as a new inquiry. While a request is in progress, the submit button is disabled and a busy flag prevents a second submission from the same form.

There is a limit: the identifier is held in the current page, so a page reload or a new tab does not preserve it. If confirmation remains uncertain, the displayed instruction is to contact the studio from the email address used for the inquiry before sending another copy. The interface does not promise that repeated submissions can always be recovered automatically.

Worked example: the visitor loses Wi-Fi

A customer submits a website request. The service saves it, but the reply never reaches their laptop. The customer sees an unconfirmed-receipt message, with their details still present. One retry with the same details retains the identifier. If the service reports an existing request whose private link cannot be recovered, the page directs the customer to email support. It does not invent a receipt or display another customer's project.

3. Check the receipt before showing success

The form verifies that the returned project reference is a nonempty string. It also checks the link against the studio service's expected HTTPS origin and exact client-page path. The link must include a token in its fragment and must not include a username, password, or query string. An unexpected address is rejected instead of becoming a clickable success link.

These checks reduce the chance that a malformed service response leads a customer to the wrong destination. They do not replace server authorization. The backend remains responsible for making sure each private token can access only its own project.

The success screen offers a copy action for the private link. If the clipboard is unavailable, the visitor receives instructions for saving the link manually. That fallback matters on browsers where clipboard permission is denied. A receipt should remain usable without requiring the customer to grant a new browser permission.

4. Explain what makes the link private

The private project link acts as an access key. Someone who obtains it may be able to view the project, send messages, and approve a proposal. A project reference by itself does not open the workspace. This makes it easier to return without a new account, but it also makes sharing the complete link consequential.

Our public client page accepts a complete supported private link and validates its destination before opening it. The private workflow is kept separate from public articles, and the inquiry form, client page, and owner workspace do not load advertising scripts. Do not copy a customer token into analytics events, public screenshots, bug reports, or campaign links.

For your own business, decide how lost or accidentally shared links will be handled before launching. Write down who verifies the requester and who can revoke or replace access. A support email alone is not proof that the sender owns a record. Our privacy notice explains the information kept with a studio inquiry.

5. Test failures as deliberately as success

Use a development copy and synthetic details for these checks. Do not repeatedly submit test inquiries to a real business or paste customer information into a test sheet. Keep the expected result and actual result together so a screenshot of a success screen is not mistaken for a complete test.

Download the inquiry test sheet (plain text). It includes space for the test environment, expected result, observed behavior, and follow-up owner. The worksheet is a local file; downloading it does not submit a project request.

Apply this to your first version

Start by defining the one record your form should create and the one confirmation your visitor should receive. Then write the timeout and retry behavior before adding more fields. If you cannot explain the result of an uncertain connection in a sentence, the workflow needs another pass.

Use the free app brief builder to define the audience and success checks. Compare public and private steps with the client workflow guide, or use the handoff checklist to assign responsibility for support and access recovery.