REVENUE SYSTEMS 5 minute read
What should happen after an enquiry arrives?

An enquiry needs a durable receipt, a named owner, the context required for a useful reply and a next action. Treat successful form submission and successful CRM delivery as separate events so a temporary outage does not quietly lose the lead.
Start with one journey you can follow
Pick one source: for example, a website enquiry for a commercial fit-out quotation. Write down what the visitor sends, where it is stored, who reviews it and what they need to do next. Follow a test record through every step. A diagram is useful only if the people and systems behave the way it describes.
Keep the initial form proportionate. Name, business email, company and a short description may be enough for an initial fit conversation. Request detailed project documents later through an appropriate channel. Decide which information is necessary before adding another mandatory field.
- Source: which page or channel brought the enquiry?
- Owner: who is responsible until it is reassigned?
- Next action: what must happen, and by when?
- Outcome: accepted, unsuitable, duplicate or still waiting?
Make acceptance mean something
In this website's intake design, an accepted enquiry is first stored durably before a receipt is returned. CRM delivery is a separate job. This is a design example, not a claim of a connected production CRM or a client result.
Give each request a stable identifier. If a visitor retries the same submission after a timeout, the system should recognize it rather than create another sales task. If they change the message, it should be handled as a new enquiry. Keep the original business context attached when the same person makes a later, different request.
Test the failure path, not just the happy path
A CRM can be unavailable after a website has accepted the form. Record the delivery state, make retries visible to the owner and separate failures that are safe to retry from writes whose outcome is uncertain. An uncertain write needs reconciliation before another record is created.
Use synthetic test details. The aim is to demonstrate that the workflow behaves predictably, without moving a real customer's information through an unfinished system.
- Send the same request twice: does one enquiry remain?
- Change the request: is its new context preserved?
- Interrupt CRM delivery: can the accepted record be found?
- Restore the connection: is the correct record delivered once?
- Simulate an uncertain write: does someone know what to reconcile?
Measure the handoff before buying more traffic
Choose a small set of operational measures: accepted enquiries, time to an assigned owner, time to first useful response, qualified conversations and unresolved delivery errors. Agree who reviews them. A faster automated receipt is not the same as a faster human response.
The first improvement might be as simple as assigning an owner or removing an unnecessary field. Use the opportunity calculator to explore the economics of a possible conversion change, then validate its assumptions against actual enquiry quality and delivery capacity.
What a sensible first scope contains
A first implementation can cover one form, one CRM, one routing rule and a documented recovery procedure. It should also name the owner, define deletion responsibilities and include a handover. Additional channels are easier to add once the first path is reliable.
The output is a process your team can operate. A long list of integrations is not a substitute for proving that one enquiry reaches the right person with the right context.
Make the next step practical.
Explore the related service, or use the growth lab to work through your starting point.