Start with a specific situation at work
A conversation about automation often starts when a familiar task becomes frustrating. Someone copies the same enquiry into several places, a manager waits for a report, or a customer calls because nobody has replied. These situations are useful starting points, but they are not yet a technical specification. First establish which step causes the difficulty, what information it needs, and what a correctly completed task would look like to the people involved.
Choose a recent example and follow it from beginning to end. Perhaps a customer submitted an enquiry on Monday, an employee copied it into a spreadsheet on Tuesday, and a colleague still had to confirm availability before anyone could answer. The obstacle might be repeated entry, unclear responsibility, or an inaccessible calendar. Automating an acknowledgement alone would not resolve all the waiting in that example.
The situations in this article are illustrative. They do not promise a particular saving or a guaranteed increase in sales. The value of automation depends on frequency, the consequences of mistakes, and whether people can use the result in daily work. A clear description of the problem therefore matters more than a long list of technologies that might be connected.
Describe the process as it actually happens
Include the awkward steps in your description. When an employee sends themselves a reminder, creates a temporary spreadsheet, or asks a manager a question in a messaging app, that is part of the real process. A polished diagram that leaves these actions out can conceal much of the work. The aim is to understand how information really reaches the next person, including the informal shortcuts that keep the business moving.
For each step, record the trigger, the input, the result, and the responsible role. For an enquiry, the trigger might be a form submission, the input the customer's contact details and description, and the result a record ready for review. If a step ends with “someone checks it”, responsibility is still too vague. A system cannot reliably route an exception when nobody has decided who should handle it.
Separate active work from waiting. A task that takes five minutes can delay a response for two days if only one person has the required access. Conversely, a small piece of repeated copying may consume substantial time across many requests. Both problems matter, but their solutions differ. One needs better availability or delegation; the other may benefit from a direct transfer of structured information.
Define one understandable outcome
“We want to automate sales” is too broad for a first project. A more useful outcome would be that every website enquiry appears in a shared list with a received time and an owner, and that unanswered enquiries are visible to the team. This can be tested with concrete examples. It does not automatically require a replacement for every sales tool the company already uses.
Select an initial measure that you can actually observe. It might be time to the first useful reply, the number of records without an owner, or corrections caused by manual copying. Record how the measure is calculated. Comparing working hours in one period with calendar time in another can produce misleading conclusions even when the underlying timestamps are accurate. Keep the definition stable while reviewing the first implementation.
Avoid choosing a target that rewards an unhelpful customer experience. An immediate automated message does not mean a question has been resolved. Consider usefulness and incorrect outcomes alongside speed. A good initial objective makes work easier for the team while giving the customer a clearer next step. It should also identify what remains outside the first phase so that expectations do not silently expand during implementation.
Compare candidate processes by benefit and risk
Evaluate possible projects using the same questions. How often does the task repeat? Is its input available digitally? Does the decision follow clear rules? What happens if the system gets it wrong? Can the result be reversed? This comparison is usually more useful than selecting the task that generates the loudest complaints. A frequent irritation can still be a poor first candidate if its rules are unresolved.
An initial trial often works best with repeatable inputs and limited consequences. Preparing an internal summary may be a more suitable starting point than automatically approving a special price. More complex decisions can still be improved, but they need clearer boundaries and more representative tests. The purpose of a modest first phase is to establish a dependable working pattern, not to pretend that every business decision is simple.
Do not choose a project solely because its demonstration looks impressive. A demonstration can use one ideal input, while daily operations contain incomplete information and unusual requests. Ask what happens if a required field is missing, an employee is away, or two people work on the same case. Those answers reveal more about the implementation effort than a smooth presentation of the happy path alone.
Make the data understandable before connecting it
Automation cannot resolve an undefined meaning. If “customer” means a company in one spreadsheet and a contact person in another, matching similarly named columns can create incorrect records. Agree on the important fields, their meaning, and where each value is maintained. Start with the information required for the selected process rather than attempting to reorganise every record held by the business at once.
Review several genuine examples, anonymised where necessary. Include empty fields, different date formats, outdated entries, and duplicates. Decide which problems can be corrected by a rule and which need a person to review them. Do not invent missing values simply to keep a workflow moving. An explicitly incomplete record is often safer and more useful than an apparently complete record containing an unsupported assumption.
Create a small list of data owners. Customer service may verify contact information, while another role maintains service availability. Software can highlight a disagreement, but somebody must still be able to decide which value is correct. Without that responsibility, automation merely moves mistakes between systems more efficiently. Clear ownership also makes future changes easier because the team knows whom to consult when a field or rule needs to change.
Separate fixed rules from interpretation
Many tasks follow explicit rules. A request without a required field is not ready for processing; a status change may require a notification; a completed item should disappear from an outstanding-work list. These actions do not necessarily need artificial intelligence. A straightforward rule is easier to test when the input structure is stable and the desired outcome can be described without interpreting free text.
AI may help summarise a long message, draft a reply, or group similar enquiries. Its interpretation should remain distinguishable from information explicitly supplied by the customer. A suggested priority is not the same as a confirmed deadline. Preserve the original message so that an employee can compare the summary with its source. Otherwise an early misunderstanding can become harder to notice as it travels through later steps.
A practical first arrangement is an automatically prepared suggestion followed by human review. The system can organise the request and suggest a category while an employee confirms the next action. After reviewing enough representative cases, the business can consider which decisions are sufficiently predictable to automate further. That progression should be based on observed results rather than confidence created by a handful of attractive examples.
Define exceptions before launch
Every process includes cases that do not fit the usual path. A customer submits twice, changes their contact details, or withdraws a request while an employee is preparing an offer. Exceptions are not minor details to postpone indefinitely. They determine whether the new process supports the team or creates extra uncertainty. Documenting a few common exceptions early often prevents larger corrections after the workflow is in regular use.
Give each exception an appropriate response. Missing information may create a waiting status. Conflicting values may require a manual review. Temporary unavailability of an external service may justify a later retry. These are different situations, so one generic error message is not enough. The status should explain what happened without exposing unnecessary technical detail or leaving the employee to guess whether the customer has already been contacted.
Make the next action visible. Can the task be retried? Has the enquiry been saved? Was a message sent? Will a correction affect only this record? Understandable failure handling is part of the product, not merely a log entry for a developer. It also reduces support effort because employees can resolve ordinary situations without requesting technical assistance for every interruption.
Prevent accidental duplicate actions
A network interruption can leave a sender unsure whether the recipient completed a request. The user clicks again or software retries the operation. If every attempt creates a new record, the result may be duplicate enquiries and repeated messages. This possibility exists even in a small workflow and should be considered before automating actions that have visible consequences for customers or employees.
The process needs a way to distinguish a new task from another attempt at the same task. An implementation may use a unique request identifier and a stored outcome. The business acceptance criterion is simpler: retrying one operation must not silently perform it twice. A test should simulate an interrupted response, not merely submit two requests under perfect network conditions and assume that covers the problem.
Also consider legitimate repetition. The same customer can place two different requests, and those should not be merged merely because their email address matches. Duplicate detection must follow the meaning of the process. The question is whether this particular action has already been completed, not whether the company has seen the person before. Clear distinctions protect both the customer experience and the accuracy of reporting.
Keep practical control in human hands
An automated process should remain visible after launch. The team needs to understand which tasks are waiting, completed, or in need of assistance. That does not always require a new dashboard. An existing shared list with dependable statuses may be sufficient. Choose the simplest place where the relevant people will actually look, and ensure that it reflects the current state rather than an occasional copy.
Decide who can change rules and who can only handle individual cases. An employee correcting a telephone number does not need access to the entire technical configuration. A maintainer investigating a failed transfer should not automatically receive unrelated business information. Separating these responsibilities makes routine work easier and reduces the chance that an ordinary correction changes the behaviour of every future request.
Provide a clear way to pause new automated actions. If results become incorrect, the responsible person should be able to stop the affected step and continue essential work manually. Agree where unprocessed tasks remain and how they are resumed. A pause must not erase the evidence of incoming customer requests. Test this procedure before it is needed during a busy period, when improvisation is least helpful.
Test with representative cases
One correctly completed form is not an adequate test. Include an ordinary request, missing information, a repeated operation, and a temporarily unavailable connection. Write the expected outcome before running each case. Otherwise it is easy to describe whatever happened as acceptable afterwards. A useful test records the input, expected result, actual result, and any correction required to make the behaviour match the agreed process.
Initial checks can run in a separate local environment using invented data. This helps verify logic without sending real customer messages or initiating payments. However, a local result does not prove that an external mail service or public deployment works. Record that distinction and verify the necessary connections at the appropriate deployment stage. A clear evidence trail is more useful than a broad statement that everything has been tested.
Ask an employee who normally handles the work to complete several scenarios without developer guidance. They may notice unclear statuses, missing context, or an awkward handover that a technical check cannot detect. Record questions as well as errors. A frequently repeated question can show that the workflow does not explain the next step well enough, even when its underlying code returns the expected response.
Introduce the change in controlled stages
The first stage can prepare a result for comparison with existing work. For example, automation creates a draft report while the team continues its normal approval process. A temporary parallel run helps reveal differences before external actions become automatic. Keep this arrangement time-limited and purposeful. Otherwise the business may end up maintaining two permanent processes and lose the efficiency the project was supposed to create.
Next, introduce the process for one service, one team, or a manageable group of enquiries. Clearly identify which cases use the new route. If some employees maintain an old list without an agreed handover, the business can develop conflicting versions of the same information. Communication about the change matters as much as the connection itself. Everybody involved should know where to find the current record.
Prepare a recovery plan before switching over. Identify the previous working state, the responsible person, and how unfinished tasks will be accounted for. The document can be short, but it must answer a practical question: what do we do if this does not work tomorrow morning? Having that answer ready reduces the temptation to make hurried and poorly documented corrections directly to important records.
Include maintenance in the decision
Initial implementation is only one part of the commitment. Identify the services needed during regular operation, who will review failures, and what happens when an external system changes its interface or rules. A small workflow does not automatically need elaborate infrastructure. The arrangement should fit the real workload and the team's ability to maintain it, including the tools and access they already have.
Separate development work, third-party charges, and later changes. If AI is used, agree when it runs and how consumption is controlled. Transparent categories make alternatives easier to compare than a single unexplained total. They also prevent a low initial estimate from concealing recurring requirements that become visible only after launch. The relevant question is the cost of operating a useful process, not just building a demonstration.
A maintenance agreement should explain access, issue reporting, and responsibility for content or rule changes. It should also describe what happens when the relationship ends. The company needs to retrieve its information and understand which services are required for continued operation. These arrangements are easier to make calmly at the beginning than during an urgent transfer after a problem or a change of supplier.
Example: handling enquiries in a service business
Imagine a business receiving requests through its website and email. An employee copies them into a spreadsheet, checks availability, and prepares a reply. Some messages become difficult to find in the shared inbox, while the manager cannot easily see who is still waiting. The first objective could be visibility of every enquiry rather than a completely automated sales decision. That is a narrower and more testable improvement.
The initial solution saves a website request, gives it an identifier, and shows it to the responsible employee. The employee adds missing details and records the next step. Email requests can initially be entered into the same list manually. This creates one shared process without immediately attempting to interpret every type of incoming message. More sophisticated assistance can be added once the team has verified the basic handover.
Acceptance cases include a repeated submit click, an incorrect address, and an absent employee. A satisfactory result means one saved request, an understandable status, and responsibility that another person can take over. Only after checking that foundation should additional summaries or connections be considered. The example illustrates a decision-making approach rather than a universal package suitable for every organisation or every customer journey.
Prepare for the first discussion
Bring a short description of one process and a few anonymised examples. List the systems involved, the responsible roles, how often the work occurs, and the problems that repeat. An initial assessment should not require sending passwords or a complete customer database. Access can be arranged later through an appropriate method once the necessary scope is clear and the implementation approach has been agreed.
Write down what you want to preserve as well. The existing calendar may work well even though copying enquiries does not. A particular approval step may be important to the business. These boundaries help avoid unnecessary replacement of working tools. A useful brief describes both the desired improvement and the strengths of the current process, so that efficiency does not come at the expense of something valuable.
The discussion should lead to a defined first phase: what changes, how it will be checked, and what remains for later. CANIMAPS DIGITAL can help examine the process, define an appropriate scope, and implement the agreed automation. Start with a concrete situation from your daily work so that the proposal reflects your business rather than a general promise about what technology might theoretically do.