Skip to content

Use case / Inbound opportunity handover

Lead generation automation.
Give the next person a useful enquiry.

A new enquiry is only useful when someone can act on it. A custom system can connect the source, service-area rules, customer history and current capacity, then prepare a relevant response and a checked CRM update.

An original fictional example of an inbound enquiry handover. It illustrates a proposed design, not a live campaign or measured client result.

Connect the whole handover

Example system · Simulated business data

One enquiry.
A traceable next step.

Original fictional workshop enquiry ENQ-208. These are designed outputs, not a running integration or an executed response.

01 / Source

Keep the permission context

FORM-208 asks for contact about one workshop request. Marketing permission is not assumed. The source event and submitted details travel together.

02 / Match

A returning customer, a new job

Contact matches fictional customer C-042. Event ENQ-208 is new. An exact repeat of FORM-208 is ignored as a duplicate event, not a second opportunity.

03 / Check

Use actual business rules

The example's rule sheet allows Site A and requires an owner check of the requested week. No arbitrary lead score replaces service fit or capacity.

04 / Review

Make the open decision visible

The complete packet contains site, attendee count and requested window. Operations approves the scope in this scripted example. No real approval is sought or issued.

05 / Draft

Say only what was established

Draft response acknowledges one workshop at Site A and asks the customer to confirm the proposed next discussion. It does not claim an appointment has been reserved.

06 / Confirm

Read the saved result

Fictional receipt CRM-208 points to ENQ-208 revision 1, C-042 and owner Operations. Expected fields match the saved record in the example. No CRM is contacted.

The returning enquiry

Revision 2 adds a second site and changes the week.

The customer match remains. The old scope approval does not. Site B access and the new week's capacity need a fresh decision, so the response draft and delivery handover stay held.

Read the held packet and revised draft

Known ENQ-208 revision 2 belongs to C-042. The caller now wants two sites in the following week. Missing Site B access contact and confirmed capacity. Next owner Operations. Write boundary Save the revised request as awaiting review only after confirming the record version. Do not mark it accepted.

Fictional draft Thanks for the updated brief. We have noted the second site and your preferred week. Could you send the access contact for Site B? Our team will check capacity before confirming the next step.

Start with a person who has made an enquiry

The example begins with a fictional website request for a workshop at a customer's premises. The form records what the person asked for and how they want to be contacted about that request. It does not assume that submitting an enquiry also means permission for unrelated marketing.

We keep the source reference with the request so the receiving team can understand where each detail came from. A required field that was not supplied stays missing. The system should not fill a gap with a plausible invented company size, budget or urgency score.

Marketing is a separate scope. ACMA's guidance says marketing messages require consent, sender identification and an easy unsubscribe path. A bought address list or an enquiry about one job should not silently become a broad automated nurture campaign. Establish the intended communication, permission record and current requirements before enabling it.

Match the customer without losing the new request

A returning contact may be asking for a different job. Match a stable customer identifier where available, then preserve a separate request ID and source version. An exact form-event repeat should not create a second opportunity. A genuinely changed brief should not disappear as a duplicate.

If the contact address matches but the organisation or site differs, hold the association for review. Two records with similar names are not enough to establish identity. The matching policy should name which facts are sufficient and which combination needs a person.

The original example uses an existing fictional customer C-042 and a new request ENQ-208. The first version asks for one site. A later message adds a second site and changes the week. That revision retains the customer link while reopening the scope and capacity decision.

Use your actual rules to decide what happens next

Qualification can be ordinary rules. Does the requested work fit your services? Is the location inside the area you actually cover? Is there enough information to estimate the work? Who can decide when capacity is uncertain? Those questions are more actionable than a decorative score out of one hundred.

Store the source and version of the service-area and capacity rules used by the example. If the second site is outside the current rules or no availability record exists for the new week, the response should ask for a decision. It should not infer a booking slot or issue a commitment based on stale capacity.

A useful review packet separates known facts, missing details and the proposed next step. The salesperson can see what changed without reading every earlier message. The operations owner can confirm whether the requested work is feasible before a customer receives a promise.

Prepare a response that respects what is still unknown

A draft can acknowledge the actual request, restate the known scope and ask for the one missing detail. It should not invent a quoted price, claim a date is reserved or say a person has approved the work. The permission boundary decides whether a narrow acknowledgement may be sent automatically or whether a human reviews every response.

In this example, the changed request produces a held draft asking for access details at Site B. The reviewed complete request can update the CRM with the current brief, source references and named next owner. A saved-record receipt is checked against the expected request ID and fields before the workflow marks that write confirmed.

A timeout is ambiguous. The CRM might have accepted the update even though the response was lost. Check the destination before retrying a write that could duplicate the opportunity or send a second response. Keep the affected request visible until the outcome is known.

Measure a handover your team can use

Track whether the enquiry reached the correct owner, whether required facts were present and how long the team spent checking the draft. Count missing requests and repeated records as well as explicit errors. Do not use a simulated walkthrough as evidence of conversion uplift.

Before building, agree what a complete request looks like and collect representative examples. A pilot can establish the actual exception rate and review effort. That gives you a better investment case than assuming every captured lead becomes revenue.

The implementation scope depends on source permissions, current application capabilities, response approval and the records you need to keep. Our normal build and care framework applies to agreed custom work. We quote the process after discovery, with the delivery and ongoing responsibilities made explicit.

Before you decide

Your questions, answered

Does this generate new leads automatically?

This example improves the handover of inbound enquiries you receive. It does not demonstrate a traffic source, an executed outreach campaign or guaranteed new lead volume.

Can the system email every contact in our database?

That is not the scope shown here. Marketing requires a separate permission and communication design, including current consent and unsubscribe requirements. An inbound request does not silently authorise every future message.

What happens when a returning customer changes the brief?

The customer association can remain while the request gains a new revision. Changed scope, dates or sites reopen the relevant decisions. The previous approval is not treated as permission for the new work.

Is the CRM update on this page real?

No. The record IDs and receipt are fictional design outputs. They illustrate the fields and confirmation a real implementation would need, without contacting a CRM or sending a response.

Sources and checks

References support the specific facts discussed above. Check dates show when each source was consulted. Vendor features and rules can change.

A useful first conversation

Bring an enquiry your team could not act on

Show us where the request arrived, what was missing and who needed to act. We can work through a useful first scope.

Book a call