Map an enquiry to an assigned task and reviewed reply

Give the request an owner before it gets lost.

A customer asks a plumbing business about a dripping kitchen tap. The request reaches a shared inbox. One person assumes a colleague will answer; the colleague assumes somebody is checking availability. The missing step is a clear owner and next action.

You can map that handoff in a notebook or a shared document before buying software. Use the worksheet below to describe where the enquiry arrives, what is needed, who reviews it and what happens if the handoff fails.

What happens when nobody is available?

Receiving an enquiry does not mean the job is accepted or someone is responding now. In your real map, record staffed hours, the next staffed review, a primary and backup role, and what the customer is told while waiting. Keep out-of-area, urgent and unclear requests in a named exception queue. Do not promise emergency or round-the-clock coverage unless that service actually exists.

The sample does not check a real rota, calendar, phone line or service area. Its priority label is a fictional routing result, not a promise of an emergency response. If a real handoff fails, keep the request visible and use the agreed manual queue until a person confirms the next step.

Map five steps and their exceptions.

In this sample, routine plumbing and general requests go to the Service coordinator. A quote request goes to the Quotes team. A priority word such as “burst” or “urgent” sends it to the Duty manager for review, including an urgent quote. These simple rules do not understand every situation, dispatch help or confirm availability.

Keep the request, owner and decision together.

This mapping uses the sample’s New job example. In your own process, replace these labels with the fields in your inbox, form or job system. Do not assume similarly named fields in two tools mean the same thing.

The demo needs a name, a valid example email and a nonempty message. An empty area or a message shorter than 20 characters produces a clarification draft. Those are illustrative checks, not a complete assessment of whether a job can be booked.

Try four paths, including the awkward ones.

Open the enquiry sample and follow these steps. Each separate test starts with Reset demo. Keep the same queue for the duplicate test. These outcomes were checked against the sample on 8 October 2026.

Resetting, reloading or switching workflows clears the sample. Its queue holds up to 20 enquiries; it is not a durable job record. The failure example is a controlled simulation, not a test against an unavailable customer system.

Copy this worksheet into your own process.

No signup is needed. Copy the text into your notes and replace the brackets. Use actual names for owners and backups. Start with one inbox and one type of request; leave anything you do not know marked “unknown” for the process owner to resolve.

ENQUIRY HANDOFF WORKSHEET
Business or team: [name]
Process owner and backup: [person / person]
Reviewed on: [date]

1. RECEIVE
Where requests arrive: [inbox / form / phone notes]
Where the original request is kept: [record or folder]
How we identify one enquiry: [reference]
Person checking new requests: [name]

2. CHECK DETAILS
Details needed for the next action: [list]
Where customer contact preferences are recorded: [place]
Missing-detail owner and next review time: [name / time]

3. ASSIGN
Routine requests go to: [name]
Quote requests go to: [name]
Priority requests go to: [name]
If that person is unavailable: [backup and handoff]

4. REVIEW
Draft prepared in: [place]
Person allowed to approve: [name]
Check before approval: [recipient / latest conversation /
details / promises / contact preferences]

5. RECORD THE NEXT ACTION
Outcome recorded in: [place]
Next action, owner and review date: [action / name / date]
How we know the handoff succeeded: [evidence]

EXCEPTIONS — NAME A PERSON FOR EACH
Missing details: [name / action / next check]
Possible duplicate: [name / compare / keep or link]
Urgent or unclear request: [name / escalation]
Connection failure or uncertain outcome:
[name / pause / check destination / approve recovery]
Reply, opt-out or changed request:
[name / update record / stop or change next action]

SMALL REHEARSAL BEFORE ANY LIVE CONNECTION
One complete request: [expected / observed]
One incomplete request: [expected / observed]
One repeat of the same request: [expected / observed]
One interrupted handoff: [expected / observed]
Unresolved differences and owner: [notes / name]
Accepted by and date: [name / date]

Walk a fictional request through the map with the people responsible. Check that each person knows where to find it, what they may decide and how to pass it on. A blank exception owner is a useful finding: resolve it before depending on an automated handoff.

What a real CRM connection would still need

The browser queue shows the decisions. Connecting your inbox or CRM is separate implementation work. First check whether the tools you already have can perform the handoff. Then agree these details for the specific system and account:

1. 1

   Access and permissions

   Confirm which account owns the connection, which records it may read or change, and who can revoke that access. Check actual connector availability and any tool costs.

2. 2

   Exact field mapping

   Record the real source and destination field IDs, required values and allowed statuses. Confirm whether you are creating a contact, an enquiry or a task, and retain a link to the original request.

3. 3

   Duplicate and update rules

   Choose how a repeated delivery is identified, how a second job from the same person is handled, and what to do when an existing request changes. The demo’s email/area/message comparison is only a local example.

4. 4

   People and review boundaries

   Name the owner for routine work and every exception. Decide which actions need approval and where the latest reply or contact preference is checked before the next action.

5. 5

   Acceptance and recovery

   Test complete, incomplete, repeated and interrupted handoffs in the agreed environment. Check the actual destination record and any message outcome. Record how to pause, who investigates, and who approves a retry when the result is uncertain.

When an answered enquiry goes quiet

Intake ends with a clear next action. If your team has replied and the customer later goes quiet, use the separate follow-up checklist to check the latest conversation, timing and stop conditions before another message.