Some processes change because the business is learning. A team experiments with a new offer, receives different questions or discovers that information is missing from a form. Those changes may improve operations, but they make it harder to define an automation that remains correct over several weeks of use.
The starting point is to observe where the change occurs. A process can contain an unstable commercial decision alongside a predictable data collection stage. Treating those parts differently allows progress without turning a temporary assumption into a rule hidden inside the system, where people may forget that it still needs validation.
Distinguish stable stages from decisions still being explored
Divide the process into stages and identify which have changed in recent uses. Distinguish changes in format, changes in decision criteria and isolated exceptions. Collection and recording may be stable while the next decision remains unresolved. This separation helps you choose an initial scope that the team can realistically support and maintain.
Imagine a process for receiving quotation requests. Recording the date, contact details and original message may be stable. Choosing the appropriate offer may change because the business is testing different services and the commercial owner still needs to interpret each request using knowledge that has not yet been formalised.
In this example, automation can organise information without choosing which proposal to send. The work becomes easier to track while the team retains the freedom to learn. Once a consistent criterion exists, that stage can be reconsidered using examples of requests that have already been handled.
An inventory of tasks and their owners helps identify these boundaries. Add a simple indication of stability: what remains unchanged, what has changed and who makes the decision when there is uncertainty about a particular case.
To prepare your next step, explore Automating administrative tasks.
Separate collection, interpretation and action
Organise the automation so it distinguishes incoming data, the interpretation of that data and the action that may follow. This makes changes easier to locate. If a commercial rule changes, you should be able to revise the interpretation without losing the original message or repeating actions that have already been completed.
A message received from a potential customer is source information. The category assigned by AI is an interpretation. Sending a reply or creating a proposal is an action with consequences. When these are mixed together, it becomes difficult to establish which part requires correction and what information should remain intact.
Preserving the source lets you revisit earlier decisions under a new criterion when appropriate. It also allows comparison between the system's suggestion and the responsible person's decision. The team gains concrete examples for improving instructions rather than relying on memories of what happened with previous requests.
The choice between rules and AI in an automation matters here. A predictable stage can follow an explicit rule; a message written in free language may require interpretation. Using AI in one part of a process does not require using it in every other part.
Keep human review where a clear criterion is still missing
When the team cannot yet explain a decision consistently, use automation to prepare information and keep a person responsible for the decision. Give the review a specific question and record its outcome. This makes it possible to learn from exceptions and see whether the underlying criterion is becoming clearer with experience.
For quotation requests, AI can summarise the need and suggest a category. The responsible person checks that the summary preserves the request and selects the final category. Rejecting the suggestion becomes useful when the reason is recorded: missing information, two separate needs or an outdated category definition.
A vague review in which someone clicks approve without knowing what to check does little to stabilise the process. Specify which elements must be present and which situations require clarification. The reviewer should be able to explain why a case is ready to move forward or needs to remain pending.
As examples accumulate, look for patterns in the corrections. Repeated uncertainty may reveal a missing business rule or form field. Addressing that cause is usually more useful than adding lengthy instructions to compensate for information that never reached the system in the first place.
Record the rule in effect whenever you make a change
Keep a short record of changed rules, the reason for each change and the person who decided it. Identify the version currently in use and when it takes effect. This context helps explain differences in behaviour and prevents comparisons between results produced under criteria that are no longer the same across cases.
The record does not need to begin as a complex system. A table containing the date, change, reason, owner and affected examples may be sufficient. What matters is being able to explain what changed when someone asks why two similar requests received different treatment at different moments.
Distinguish a deliberate change from an error correction. In the first case, the business has chosen a new criterion; in the second, the system was failing to follow the intended criterion. That distinction affects whether earlier requests need review and how the change should be explained to the team.
Also define what happens to cases already in progress. A new rule may apply only to future requests or may require earlier ones to be reviewed. Leaving that choice implicit can create duplicate work and different expectations between the person receiving a request and the person responsible for completing it.
Test the change with cases the team already understands
Before applying a new rule, use examples with expected outcomes that the team understands. Include common situations, incomplete information and relevant exceptions. Compare behaviour before and after the change. The aim is to confirm the intended improvement and identify effects on other parts of the process that should remain stable during use.
If a change is intended to distinguish two request types, test examples of both and an ambiguous case. Confirm that other categories still work correctly too. Resolving one specific example is insufficient when the same instruction is used across the entire flow and may affect unrelated decisions.
Testing an automation before handing it to the team should include changes over time. Keep useful examples so the next revision can repeat the comparison. The accumulated experience then supports future changes instead of being lost after each individual fix.
If the change does not produce the expected result, keep the earlier version or limit the change to a controlled trial. Avoid introducing several changes simultaneously while you still need to understand which one explains an improvement or an error observed during testing.
Increase autonomy only when the process supports it
Autonomy can increase when inputs are understandable, criteria are clear and exceptions have a defined treatment. Decide that increase stage by stage using the evidence collected. One part of the process can run automatically while another still requires review, without preventing the business from benefiting from the work already completed successfully.
One possible sequence is to start with collection, move to preparing a draft and then authorise a limited action. Each transition needs an observable reason. The team should be able to explain what it learned that justifies removing a check or expanding the set of cases the system may handle.
Keep a way to reduce autonomy again when the context changes. A new offer, a different channel or changes in source data can invalidate assumptions that were previously reasonable. Human review may become necessary again in a stage that had already been automated successfully under earlier conditions.
Automating an evolving process requires keeping pace with the business's learning. The useful work is making stable stages simpler to execute, preserving information for decisions and allowing understandable changes. In that way, automation supports the process while leaving room for decisions that still need to mature through experience.