Your first automation should solve one real problem

Start with a repeated problem you can describe

A business asks to automate its marketing, but the team has not agreed who should receive a new enquiry. Automating that ambiguity can make the confusion faster. A better first project is a small workflow with a visible starting point, a clear owner and a way to recognise success or failure.

First Thought’s automation offering is a developing pilot direction. The framework here describes how we propose approaching a first workflow; it is not a claim that we have already delivered every integration or a promise that a tool can replace the team’s judgment.

Draw the current process before choosing software

Write the journey as a sequence: enquiry arrives, record is created, owner is assigned, follow-up happens and outcome is recorded. Note where the team currently copies information, waits for a response or loses track of responsibility. Ask the people doing the work to check the diagram.

Choose one specific failure to address. For example, the first pilot might ensure that a website enquiry reaches a private directory with its source and assigned status. That is easier to test than a vague project to automate the entire customer lifecycle. The chosen system should support the process rather than dictate it without discussion.

Separate a rule from a judgment

Some decisions can be expressed clearly: route an enquiry for a particular service to a named team, or create a task when a required field is present. Other decisions need interpretation: whether the project is a good fit, what proposal to recommend or how to handle a sensitive customer concern.

Keep human review where context matters. If AI is introduced to summarise an enquiry, verify the output against the original and make uncertainty visible. An AI-generated summary should not silently invent a budget, commitment or deadline that the prospect never supplied.

Plan the failure paths first

What happens if the destination is unavailable? What happens if the same submission arrives twice? Can the team identify an incomplete record? Who notices a failed handoff? These questions belong in the initial scope, not in a later emergency after the process has begun receiving real enquiries.

A useful workflow acknowledges receipt only after the receiving system accepts the record. It provides a clear error when saving fails and lets the visitor retry without rebuilding the entire enquiry. Staff should have a practical way to take over when a step cannot complete automatically.

Collect only the information the workflow needs

Explain what will be saved and how it will be used. Limit access to the people responsible for handling the enquiry. Avoid putting credentials or private records into public pages, logs or messages. Decide how the team will correct a record and respond to a request about submitted information.

A WhatsApp handoff can be straightforward: let the visitor review a short summary, open the business chat and choose whether to send it. Opening WhatsApp is not the same as sending a message, and neither guarantees that an agent is immediately available. The interface should describe those steps accurately.

Test with realistic but fictional examples

Try a complete enquiry, an incomplete enquiry, an invalid contact, a repeated click and an unavailable destination. Check the visitor’s message and the staff-facing record. Confirm that required fields are enforced on the server, not only in the browser, and that unauthorised users cannot read the directory.

Keep test records identifiable and remove those fixtures after verification. Do not use real customer details simply because they are convenient. A small, repeatable test set helps the team evaluate later changes without exposing unnecessary information.

Decide whether the pilot earned expansion

Review whether the workflow reduced a defined problem, whether the team can operate it and whether failures are visible. Record the maintenance owner and the conditions that require a manual intervention. Expand only after the first process is understood. A modest, dependable handoff can be more valuable than an impressive demonstration that nobody can support once the original builder leaves.