A website enquiry needs a named owner, a visible next action and a record of what happened. Map the journey through received, validated, assigned, contacted and closed states before connecting forms to a sales tool. A notification alone does not tell your team whether anyone has taken responsibility.
This guide focuses on the work after submission. You can use its handover map with a shared register, a CRM or a custom system. The important starting point is an agreed process that staff can explain without referring to a particular app.
Follow one enquiry across the team
Consider a fictional office-furniture installer. A visitor asks about fitting out a workspace. The enquiry reaches an inbox, an administrator checks the request, and a salesperson discusses the scope. An operations coordinator joins later if a site visit is needed.
Without explicit ownership, each person can reasonably assume somebody else is handling it. The map below gives each stage an exit condition. These are suggested operational definitions for the fictional business, not universal CRM settings.
| State | Responsible lane | Evidence needed to move on |
|---|---|---|
| Received | Intake administrator | Request recorded with a reference and receipt time |
| Validated | Intake administrator | Genuine request, usable contact route and duplicate check |
| Assigned | Sales coordinator | Named owner has accepted the next action |
| Contacted | Assigned salesperson | Contact attempt and outcome recorded |
| Closed | Assigned salesperson | Outcome and reason recorded; no unexplained open task |
“Contacted” needs a second detail: was the customer reached? A sent email, unanswered call and completed conversation should not look identical. Keep the broad state simple, then record the contact outcome separately.
Make every transfer explicit
Decide what acceptance means
A handover should include the reference, customer request, relevant history, next action and due time. The receiver accepts responsibility through an agreed action, such as updating the owner field. Merely copying someone into an email is too ambiguous for this process.
Keep the previous owner responsible until acceptance, or define a coordinator who owns the unassigned queue. Choose one rule and teach it. If two teams must contribute, retain one lead owner and give the other team a specific task.
Define a useful clock
Set response targets from actual staffing and service expectations. Specify working days, business hours and the timezone. A request arriving after closing time should not silently receive a promise your team cannot meet.
Use separate timestamps for receipt, assignment and first contact attempt. They answer different questions: is intake delayed, is ownership delayed, or is follow-up delayed? Avoid changing the original receipt time when a record is reassigned.
Walk through a difficult example
In our hypothetical workflow, request ENQ-014 arrives on Friday afternoon. The coordinator assigns it to a salesperson who is away. The record remains in an awaiting-acceptance queue rather than being treated as actively handled.
The backup coordinator sees the unresolved transfer, chooses an available owner and records why it changed. The new owner checks the existing conversation before responding. If the customer has already sent the same request through another route, the records are linked and one is marked as a duplicate after review.
This example tests four requirements: absence cover, assignment acceptance, visible history and duplicate handling. A polished notification template would not resolve any of them by itself.
Test the handover before automating it
Use fictional records to rehearse a normal request, a duplicate, an unavailable owner and an unanswered contact attempt. Ask a colleague unfamiliar with the request to identify who owns it and what happens next.
Record defects as specific observations: “The backup cannot see the last contact outcome” is more useful than “The system is confusing.” Agree who checks the queue during normal operation and who investigates a failed transfer. Tralionex's business automation service describes workflow and exception planning as areas to scope; bring this map when discussing the next step.
Agree what a handover record must contain
Create a compact handover card alongside the state map. It should identify the enquiry reference, current owner, latest customer request, last contact outcome, next action and due time. Add any dependency preventing progress, such as a missing measurement or an internal estimate. Keep factual notes separate from assumptions so a replacement colleague knows which details still need confirmation.
For the fictional furniture installer, a useful next action is “Confirm whether installation includes the meeting room after reviewing the supplied floor plan.” “Follow up soon” does not explain the decision needed. The card should also show who is responsible for obtaining that answer. Otherwise a request can have an owner while its actual work remains unassigned.
If the enquiry originates on a public website, include a stable reference that survives the transfer into internal tools. During website development, discuss how successful receipt and internal record creation will be checked. The customer-facing success message and the staff-facing record should describe compatible states.
Handle waiting without losing responsibility
Waiting is a reason for a pause, rather than a reason to remove ownership. Distinguish waiting for the customer, waiting for an internal team and waiting for a supplier. Each condition needs a next review point appropriate to the situation. The person responsible can then explain whether progress depends on an unanswered question or unfinished internal work.
Suppose an estimator needs a dimension before preparing the installation scope. The salesperson remains the enquiry owner, while the estimator owns the estimating task. The record identifies who will ask the customer for the measurement. Once it arrives, the salesperson updates the shared record rather than forwarding a detached message that may never reach the estimator.
When several requests concern the same project, link them under an agreed project reference while preserving their individual questions. Combining everything into one long note can conceal an unresolved item. Keep a simple list of outstanding decisions with an owner and status for each.
Review common handover mistakes
One common mistake is assigning a department instead of a person or an actively managed queue. “Sales” may be a useful routing destination, but somebody must accept responsibility for its contents. Another is treating reassignment as completion: the previous owner has passed the work onward, yet the customer still awaits an answer.
A third mistake is recording activity without an outcome. “Called customer” omits whether there was a conversation and what was agreed. Ask staff to record the useful result concisely, avoiding unnecessary personal information. Do not impose long narrative updates that nobody has time to maintain.
For the first operational review, inspect a small mixed sample: a completed request, an unresolved request, an absent-owner transfer and a duplicate. Reconstruct their journeys from the records alone. Use gaps to improve the map and instructions before adding more automated messages or dashboards.
Frequently asked questions
Does every enquiry need a CRM?
No. First establish ownership and status rules. A shared register may support a simple workflow if the team can maintain it reliably.
Who owns an enquiry while someone is away?
Name a backup role in advance. Make the transfer visible and preserve the previous history rather than starting a disconnected record.
When should an enquiry be closed?
When the team records a defined outcome, such as work agreed, declined, duplicate or no response under an agreed follow-up policy. Closure should have a reason.
Is an automatic acknowledgement enough?
It confirms receipt only if the message says so accurately. Staff still need an owner and next action for the actual request.
Plan your next project with Tralionex
Bring one enquiry journey, its current handover gaps and the people responsible for each stage. Tralionex can discuss a defined website-to-team workflow, including ownership, exception handling and the acceptance checks needed for your project.
