Which workflows should you automate first?

Map the current workflow honestly

Write the trigger, inputs, actions and outcome. A hypothetical service business may receive enquiries by email, copy details into a shared sheet and send a standard acknowledgement. Include the informal work: clarifying missing information, correcting duplicates and asking a colleague for context. Those exceptions often determine whether automation is suitable.

Observe the people doing the task rather than relying only on a managerial summary. Ask where they use judgement and what information they check outside the documented process. A workflow that appears repetitive may contain important decisions. Make those decisions explicit before proposing a rule or model that would act without the same context.

Separate repetition from judgement

Identify steps with clear rules and stable inputs. Copying an approved field, checking a required value or routing a request by a confirmed category may suit automation. Deciding whether a sensitive complaint deserves an exception may need a person. Do not treat language complexity as the only distinction; a short request can still carry substantial risk.

For the enquiry example, an assistant might draft a summary and flag missing details while a person approves the reply. That is an illustrative boundary, not a live DG Vers capability claim. Starting with assistance rather than autonomous action can make the workflow easier to evaluate. The appropriate boundary depends on the consequences of a mistake and the reliability of the available information.

Assess inputs and system access

List where data comes from, its quality and who owns it. Inconsistent names, incomplete fields and duplicate records should be handled deliberately. Clarify what the bot is permitted to read and change. Use the least access needed, and keep credentials in an appropriate secret-management process rather than a document or source file.

Check the receiving system's supported integration method and failure behaviour. Do not assume a screen-based action will remain reliable when a layout changes. Identify dependencies that need confirmation. If an integration is unavailable, a partially manual workflow may be more sensible than a fragile workaround that quietly fails or broadens access to private data.

Model exceptions and recovery

Ask what happens when an input is missing, contradictory or outside scope. Define a safe stop, a queue for review and a clear owner. A failed record update should not trigger repeated messages or silently disappear. Decide whether retries are safe and how duplicates are identified. These behaviours belong in the scope, not in a later maintenance discussion.

For the service business, an enquiry with an unknown category might go to a human review queue instead of being forced into a guessed service. A customer should not receive a confident answer based on missing information. Keep the handoff understandable and provide the person with useful context while avoiding unnecessary exposure of private details.

Compare value with maintenance effort

Estimate the recurring work the automation removes and the work it introduces: monitoring, source updates, exception handling and integration maintenance. Use observed task information where available and label estimates as estimates. Do not promise a fixed saving before the process has been measured. A small automation that is dependable may be more useful than a broad system requiring constant supervision.

Run a bounded pilot with clear acceptance criteria. Compare proposed actions with human review before allowing consequential changes. Record error categories and review the most serious cases first. Agree when the pilot should stop or return to a manual process. An automation project needs a recovery path just as much as a success path.

Automation opportunity checklist

• Map triggers, inputs, actions and informal exceptions.
• Identify judgement and consequences of mistakes.
• Confirm data ownership and minimum system permissions.
• Check supported integrations and dependencies.
• Define safe stops, retries and human review.
• Compare maintenance effort with plausible operational value.
• Pilot with acceptance criteria and a manual recovery path.

Bring one documented workflow to the first development discussion rather than a request to automate everything. A narrow, well-understood scope makes it easier to agree boundaries and discover whether the proposed solution is actually useful. Expand only after the team can explain how it behaves when the ordinary process breaks.