AI or rule-based automation? How to choose the right approach for your business

If an employee moves data between applications according to clear rules, start with rule-based automation. AI powered by language models is worth testing for interpreting messages, summarising correspondence and drafting replies, provided your team can assess the output and deal with mistakes. A single process can combine AI that interprets a customer's request with rules that check the order and pass the task to the warehouse.

First, find out where employees spend their time

Walk through a recently completed request with the person who handled it: what they had to read, where they looked for data, what they copied and when they needed someone else's decision. Record why the request was delayed, too. An email may have sat in an inbox because nobody was responsible for it, even if reading it took very little time.

Suppose a customer asks when their order will arrive. An employee finds the order, checks the shipment status and prepares a reply. If switching between applications takes up most of the time, first consider giving them a single view of the information they need. If the difficulty lies in identifying different requests within long email threads, you could test AI to help organise the messages.

Talking to the employee also helps establish whether the team needs a new tool or a shared understanding of the process. If two departments interpret the status “ready” differently, they need to agree on its meaning. Transferring that status between systems faster will leave the disagreement unresolved.

When rules and connected applications are enough

Rule-based automation performs predefined actions when specified conditions are met. It can send a paid order for fulfilment, issue a reminder about a pending approval or transfer form data to a customer management system. For this kind of task, you can define the required data and what should happen in each supported case.

Start by checking the features of your existing applications. The rule or ready-made connection you need may already be available. If it is not, consider an integration: a way for applications to exchange data. The work required also depends on whether those applications make the information you need available and allow the relevant actions.

For the TimeCamp integration with monday.com, we mapped projects and users between the two platforms and built the data synchronisation mechanisms. Our work also covered data validation, error handling and retries for interrupted operations.

You can use a similar criterion to assess your own process: can you identify exactly where each piece of information should be saved? If a time entry belongs to a specified project and user, start by checking those links. When they are missing, the system should flag the issue for clarification. Rule-based automation also needs a defined response to incomplete data and interrupted connections.

When AI is worth testing

In customer correspondence, some details may appear in the first email and others in later follow-ups. A language model can help bring them together in a summary, identifying the customer's request and the conditions that matter to them.

A convincing answer can still contain incorrect information. NIST describes this risk in its Generative AI Profile, including responses that conflict with the input material. When extracting details from a message, it helps to display the original alongside the model's suggestion. An employee should be able to spot a missing order number or an important condition left out of the summary.

In TimeCamp's AI application, we are developing a mechanism that uses activity signals to suggest time entries and their project assignments. Users can review and correct the suggestions before saving them.

If checking a suggestion means doing the entire task again, the benefit may be small. In that case, consider narrowing the feature's scope, making the source information easier to review or keeping the existing way of handling the task.

One process can combine both approaches

Consider a hypothetical request to change a delivery address. AI can initially identify the request and prepare a proposed address for review. Separate rules check whether the sender is authorised to make the change, whether the order has been identified unambiguously and whether its current stage of fulfilment still allows an address change. An employee sees the original message, the proposed details and the results of those checks, then approves the action. The integration saves the change in the relevant system and confirms that it has been completed.

A single AI function at a specific point in the process may be enough. An agent that chooses its own next steps and tools needs a separate justification. Anthropic recommends starting with the simplest possible solution and notes the additional costs and potential for errors to compound as agents operate more independently. In this example, the sequence of actions is known and can be defined in advance.

Compare the full cost of handling a request

When comparing solutions, include the work needed to connect applications, ongoing fees and maintenance, as well as staff time. An AI-based solution also involves reviewing suggestions and correcting inaccurate outputs. With rule-based automation, handling exceptions and updating rules as the process changes can take up staff time.

Here is an illustrative calculation. Suppose a company handles 600 similar requests a month, each taking six minutes. That is 60 hours of work. If, after implementation, handling a request took an average of four minutes, including checks and corrections, the total would be 40 hours. The difference is 20 hours a month. Actual handling time needs to be measured during the trial.

To assess the financial benefit, establish whether that time would help reduce overtime, handle more requests or complete other necessary work. Compare the benefit with implementation and running costs over the same period. If mistakes lead to complaints or additional work in another department, include those consequences in the calculation too.

How to prepare a trial before committing to implementation

Choose one recurring type of request. Collect routine examples as well as cases with missing information, exceptions or a need to contact the customer again. Decide which materials may be used in the tool being tested and who will assess the results. Set aside some examples for a final check, so the assessment does not rely entirely on cases used to refine the solution.

Compare the current way of working with straightforward automation and, where justified, an AI-based option. Measure the full handling time, record errors and calculate running costs for each. Also agree who will take over cases that need intervention and how the team will work during an outage.

Agree specific acceptance criteria with the supplier. For the address-change example, they could be:

• If a message could refer to two orders, the system asks for clarification and leaves both unchanged.
• If the sender's authorisation has not been confirmed or the address is incomplete, the system stops the change and shows the employee why.
• After a connection is interrupted, the system marks the request as needing a check until it confirms the actual outcome of the update.
• For a complete, approved request, the system changes the address only on the specified order, provided its current stage of fulfilment still permits it.

Include each of these cases in the trial. An update to the wrong order should prevent the feature from going live until the problem has been fixed and checked again. Once the solution is in use, errors still need to be recorded and handled through an agreed process.

This gives you a basis for defining what to commission: actions performed automatically, suggestions that need approval and requests that remain with employees. The supplier knows what to price, and you have criteria for checking the work delivered.