Plan your website enquiry workflow

A website enquiry workflow describes what happens between a visitor submitting a request and someone in your business taking responsibility for it. It includes the form, the record staff use, the next action and the arrangements for requests that arrive twice or need more information.

If you are commissioning a website or connecting it to a customer management system, agree that workflow before approving the build. Your developer needs to know what the business considers a successfully received enquiry. A confirmation on the screen is not enough if nobody can find the request afterwards.

Start with one enquiry type, such as a quotation request. Decide what staff need to respond, where they will record progress and who will accept the finished workflow. You can then compare proposals against a business task rather than a list of unspecified integrations.

Define the quotation request before choosing the connection

Consider a fictional furniture workshop that wants customers to request quotations for fitted shelving. Every request, record and test below is hypothetical. The example describes requirements to discuss with a developer, not a ready-made product or a reported client project.

The workshop's owner wants staff to understand the job well enough to decide whether to arrange a measurement visit. The first form therefore asks for a contact name, a reply route, the general location and a short description of the shelving. Exact measurements are optional because a customer may need help obtaining them. Payment details, identity documents and unrelated personal information have no place in this initial request.

The owner asks the developer to explain why each required field is needed. Making exact measurements compulsory would exclude people the workshop intends to help. Leaving the reply route optional would create a request the team could not answer. These decisions belong in the brief before anyone designs the form.

The form must describe the next step honestly. In this example, submitting a request does not book a visit, reserve a production slot or accept a quotation. Staff assess the request first. The workshop will only publish a response timeframe after agreeing who can meet it, including during absence.

Choose one record that staff trust

The workshop already keeps quotation work in a customer management system. The team chooses its enquiry register as the authoritative record, meaning the place staff check for the current owner, status and next action. An inbox notification can draw attention to a request, but the team does not treat reading that notification as accepting responsibility.

This choice does not prove that the current system supports the proposed connection. The developer must check available access, supported fields, permissions and any limits before committing to an integration. If a reliable connection is unsuitable for the agreed scope, a documented manual transfer may be preferable. That option still needs reconciliation and an owner; it should not quietly become an extra job nobody agreed to do.

The completed brief for the fictional workshop reads as follows.

Use roles in the project specification, then name the actual people before launch. Agree how staff find unassigned and overdue work. An assignment rule needs a visible exception when no eligible person is available.

Follow one enquiry to an owned outcome

In the test environment, a fabricated customer requests shelving for an alcove but does not know its dimensions. The request has a usable test reply route and enough description for staff to understand the task. The workflow creates enquiry Q-104 and marks it awaiting assessment. Missing optional measurements do not prevent receipt.

The office coordinator is absent. The workshop owner opens the unassigned queue under the agreed cover arrangement, accepts Q-104 and records the next action as assessing whether a measurement visit is appropriate. The owner decides that measurements are needed before a quotation can be prepared. Q-104 changes to awaiting clarification, with the question and responsible person recorded.

The test scenario then supplies the missing information through the agreed test process. The owner records it against Q-104, confirms the job is suitable and prepares a quotation for internal review. The register records the quotation reference and next review action. When the fictional customer declines, the owner records that outcome and closes the enquiry. The business can explain who dealt with the request and how it ended.

No customer communication is sent in this exercise. The test uses fabricated identities, disabled external messaging and a separate environment. It checks the proposed staff actions and stored records without contacting anyone or creating production work.

Give incomplete and repeated requests different treatment

If the required reply route is missing or unusable under the agreed validation rules, the form should explain the problem and retain the visitor's other entries where the design permits. It must not display the same success message as an accepted request. Agree accessible error messages and how a visitor can correct the entry before release.

A request can still be complete enough to accept while needing a question from staff. Q-104's missing measurements illustrate that distinction. Record the question and owner instead of treating every incomplete specification as a technical error.

Repeated submissions need a separate decision. In one test, the visitor repeats the same submission after waiting for a slow response. The agreed design must show whether that action produced one request or more than one, and how staff identify and resolve any repeat. Ask the developer to demonstrate the chosen method and its limits.

Do not merge requests solely because they share a name or reply address. A customer may genuinely need a second quotation. In this example, a later request for shelving in a different room receives Q-105. Staff can relate the records after checking them without losing the second job. When two records really are duplicates, the coordinator records which one remains active and where the other points. Silent deletion would make the history harder to reconcile.

Let a failed acceptance test change the launch decision

The first demonstration fails an important case. The developer makes the test destination unavailable, then submits a fabricated enquiry. The screen says the request was received, but there is no destination record and no retained request in the agreed receipt mechanism. Nobody has a record to recover.

The owner declines acceptance. A pleasant confirmation message cannot justify launching that behaviour. The failed result and the missing receipt evidence go into the project's issue record, with the developer responsible for proposing a correction. This test does not involve a live form, real customer data or any email delivery.

For this fictional first release, the parties agree a limited correction. The form may confirm receipt only after the destination has confirmed that it retained the request. If that cannot be established, the page must explain the uncertainty and preserve the entered details where possible. A timeout must not be described as proof that nothing was saved. The developer must also show how staff reconcile an uncertain attempt before treating a repeated attempt as a new job.

This choice leaves a clear boundary: the first release does not promise to accept enquiries while the destination is unavailable. A separate retained queue could be considered later, but it would require its own storage, access, recovery and reconciliation design. The workshop accepts the first-release boundary rather than assuming an unspecified retry feature will solve it.

The corrected demonstration produces the following results.

• A normal test request receives a success message and a matching destination reference. The covering owner can find and accept it.
• A confirmed destination rejection produces a useful failure message and no receipt claim. The test evidence shows no new destination record.
• An uncertain response produces no definite success or definite non-receipt claim. The agreed check finds the retained record, and the repeated attempt is reconciled to it rather than becoming a second active job.
• Missing required information produces a correction message. Missing optional measurements still allow a request like Q-104 to reach staff.
• A genuine second job remains a separate request, even when the test identity matches Q-104.

The owner accepts the corrected receipt and ownership behaviour for the agreed first-release scope. That acceptance is not permission to launch the entire site. The project still needs its other agreed checks, including access, accessibility, data handling and support handover. Record who signs off each remaining condition.

Include the handover in the commissioning decision

Before approving the work, ask who can change the form's questions, who maintains the connection and who notices a failed check. Give staff instructions for unassigned enquiries, absence cover, uncertain receipt and duplicate resolution. Agree how a change to the destination system is assessed before it disrupts the website.

The business also needs to decide who may view the records, what information it keeps and when it removes it. Include the relevant privacy and security review in the project scope. This workflow example is not legal advice or a complete compliance specification, and it sets no universal retention period. Use appropriate advice for the information and activities involved.

Bring one completed request, one failure and the final ownership decision to your supplier discussion. Ask the proposed developer to explain what is included, what remains manual and what evidence will allow you to accept the work. Hosting, maintenance and ongoing support should have explicit responsibilities and scope.

My web development service covers bespoke websites and web applications shaped around customer enquiries and the way your team works. Discuss your website project with your current tools, the request you want to handle and the decisions still unresolved. We can assess the required connections and agree the build and handover before committing to functionality.