From website enquiry to back-office action, as one system

An enquiry arrives through the website at 10:14 on Monday. Someone copies it into a spreadsheet, forwards it to a colleague and marks the email unread as a reminder. On Thursday, the prospect follows up. The sales manager can see the original message but cannot tell who accepted it, what happened next or whether anyone replied.

Each tool may be working as designed. The failure sits between them. The website, inbox, spreadsheet and business application do not share one accountable record, so people rebuild context at every handoff.

Create one record before adding automation

The first improvement is simple: every enquiry becomes one record with a stable identifier. Preserve the customer's original message, source page, contact route, submission time and consent details. Add the assigned owner, current status, next action and response history as the work moves.

This record may live in a CRM, service platform, workflow application or a purpose-built business system. The tool matters less than the rule. People should know which record is authoritative and which fields other systems may update.

A shared record does not mean every department sees everything. Role-based access can hide commercial, personal or operational details that a user does not need. The goal is consistent state, not unrestricted visibility.

Design the handoffs people currently perform by memory

Map the work from receipt to outcome. For each handoff, name who sends it, who accepts it, what information must travel, how long it may wait and what happens when nobody acts.

A common enquiry path may include qualification, technical review, commercial follow-up and closure. Some requests skip stages. Others need two teams to work in parallel. The workflow should expose those differences without forcing every enquiry through a large approval chain.

Choose the integration route around the system

Some applications expose an authorised API. Others provide a reporting interface, event feed, controlled import or database route. The first assessment confirms what the source supports, which operations are permitted and how failures are reported.

Direct database access is not the default answer. A read-only account can support reporting or synchronisation when the client approves it. Write actions should use a narrow authorised service path with validation and audit. When no safe automated route exists, a generated task for a person may be the right integration.

The design should also decide which system owns each field. If the website, CRM and ERP can all overwrite the customer name, the company has created three sources of truth. One owner and clear synchronisation rules prevent that conflict.

Give AI the work it is good at

AI can read an incoming message, prepare a concise summary, suggest a service category and identify missing information. It can compare the request with an approved knowledge base and draft a response for review. These tasks reduce repetitive reading without giving the model final authority over the workflow.

Deterministic rules should handle obvious decisions. A selected service, known customer and region may be enough to choose the owner. The model becomes useful where language and context matter, such as interpreting a free-text description or explaining why a request needs technical review.

Record the model's suggestion separately from the approved value. That distinction lets the team measure accuracy and correct the workflow without losing the original evidence.

Allow controlled actions when they shorten real work

Once the read and suggestion path is stable, the application can perform approved actions. It might create a CRM opportunity, open a technical assessment task or schedule a reminder. Each action needs a defined contract, narrow service identity, validation and audit.

Higher-impact actions may require approval. A person should see the current value, proposed change and supporting context before accepting it. Retries need an idempotency key so one enquiry cannot create several records after a timeout.

Where possible, keep a reversal or compensating action. If the workflow creates the wrong task, close it with a recorded reason. If it sends information to another system, preserve the reference needed to trace and correct the outcome.

Design the exception route before the happy path goes live

Real enquiries arrive without phone numbers, use unknown company names and ask for several services at once. An integration can be unavailable. A duplicate may arrive through WhatsApp after the form submission.

These cases need a visible queue with a reason, owner and next step. Do not let them disappear into a generic error log. The people who run the process should be able to resolve a record, merge a duplicate, change an owner or retry an approved action without asking a developer to edit the database.

The original submission and audit history should remain intact. Corrections add to the record rather than rewriting what happened.

Measure flow, delay and rework

A connected process makes its weak points visible. Useful measures include time to acceptance, time to first response, records waiting without an owner, handoffs returned for missing information, duplicate entries and actions that required manual correction.

These numbers support operational decisions. If technical review causes most delays, the answer may be a better intake question or a clearer assignment rule. If the model misclassifies one service, improve the examples and evaluation set. If owners ignore notifications, changing the AI will not solve the problem.

A sensible starting point

1. Choose one high-value enquiry or service-request path.
2. Map the current steps, systems, owners and waiting points.
3. Select the system that will own the shared record.
4. Connect the website intake and preserve the source context.
5. Add assignment, acknowledgement and overdue escalation.
6. Use AI for one bounded language task and measure its suggestions.
7. Add controlled actions only where they remove proven manual work.

This first path becomes a pattern the business can extend to other workflows. It also gives the team evidence about where integration and AI create value, rather than automating a process nobody has made accountable.

Questions for the process workshop

• Where does the first authoritative record begin?
• Which context is lost or retyped at each handoff?
• Who must accept ownership, and how quickly?
• Which system owns each important field?
• Which tasks need language judgement and which follow fixed rules?
• Which actions may run automatically, require approval or stay manual?
• How will users resolve duplicates, missing information and failed integrations?
• Which delay or rework measure will show that the new process is better?

This draft uses a generic enquiry workflow. Actual integrations depend on the authorised interfaces, permissions and operating rules available in the client's environment.