Choose a first automation your team can operate.

Look for a task that somebody can explain

A team spends part of every week copying information between systems. The obvious response is to automate everything connected to it. A better starting point is a specific task with a known owner, recognisable inputs and a result someone can check. If two colleagues describe the current process differently, first resolve that difference. Software will otherwise preserve the disagreement and repeat it more quickly.

Choose a candidate with a visible finish

Useful first candidates might include preparing a daily internal report, creating a draft task from an approved request, or flagging records that need a missing field. Prefer work that occurs often enough to observe, follows reasonably stable rules and has a manageable consequence when something goes wrong. A rare, high-impact decision with many exceptions is a harder place to begin.

Write one sentence: “When this event occurs, the system prepares this result for this person to check.” Then identify where the information comes from and which system remains authoritative. That sentence defines the boundary more usefully than a promise to transform the whole operation.

Use a small operational example

Imagine a fictional maintenance business serving sites across Riyadh. Coordinators receive approved visit requests and copy the same details into a planning sheet. A first pilot could turn an approved request into a draft planning entry, preserving the site reference and preferred contact language. A coordinator would still confirm staff availability before scheduling the visit.

This example deliberately leaves some work with people. The pilot does not need to assign technicians, interpret every free-text message or promise a visit time. Success means an accurate draft reaches the coordinator with enough context to review it. Expansion can follow after the team understands the actual exceptions.

Name the exceptions before connecting tools

Walk through a missing site reference, a duplicate request, a cancelled visit, an unavailable destination system and a request edited after approval. Decide which cases should stop, which should wait and which require a person. Specify who receives an alert and where unresolved items can be found. “We send an error notification” is incomplete if nobody owns that notification.

Include language and time details in your sample data where they affect the process: Arabic and English names, international phone numbers, the relevant timezone and the team's actual working calendar. These are concrete conditions to test, not assumptions about how every MENA business operates. Use only the information the task needs and review who is permitted to access it.

Use AI only for a defined part of the work

A rule can reliably express “create a draft after approval” without asking an AI model to decide what approval means. AI may be worth evaluating for a less structured step, such as proposing a category from a message, but that adds a separate question: how will the team identify and correct an unsuitable suggestion? Keep consequential decisions with an authorised reviewer until the proposed behaviour has appropriate evidence and controls.

Do not choose an AI tool merely because the project is called automation. Compare a straightforward rule, a supported integration and an AI-assisted step against the same requirement. The technology should follow the task.

Run a pilot you can stop and understand

Agree the pilot group, observation period, sample cases and review owner. Before enabling the workflow, record the manual process well enough to resume it. Keep a visible record of what the automation attempted, what completed and what needs attention. Test pausing and restarting, including how to avoid creating the same item twice.

Review the time spent checking and correcting the output alongside any time saved entering data. Ask whether the result is more understandable and dependable for the team. A shorter task is not an improvement if it creates an unowned queue of mistakes. Bring one repeated workflow to Sabbk; we can scope the connections, exceptions and checks needed for a bounded first pilot.