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.
Use case / Inbound opportunity handover
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.
Example system · Simulated business data
Original fictional workshop enquiry ENQ-208. These are designed outputs, not a running integration or an executed response.
FORM-208 asks for contact about one workshop request. Marketing permission is not assumed. The source event and submitted details travel together.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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
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