AI vs traditional automation in Morocco: what should you automate first?

Traditional, deterministic, or rule-based automation executes defined conditions: when a valid form contains an email address, create a record; when a status becomes accepted, notify the team; when an API fails, put the item in a retry queue. Given the same input and configuration, the expected behavior remains stable and testable.

An AI step is more useful for ambiguous or unstructured input: classifying a message, extracting details from a document, summarizing a conversation, or drafting a reply. Its model output is probabilistic. It may vary, miss context, or produce something plausible but incorrect. A confidence score does not make the proposed answer a verified fact.

This is a practical distinction rather than an absolute technical taxonomy. One workflow can use both. Do not give a model a condition that fixed rules express more reliably, and do not build endless rules around a task that genuinely needs interpretation. The choice depends on risk, data, and how the output can be checked.

Assess each process by frequency, volume, rule stability, input variability, the risk level of an error, reversibility, and whether a responsible owner exists. Add data quality and the ability to measure the result. High frequency alone is not enough when every case involves a sensitive legal, financial, or commercial judgement.

Look for a concrete source of friction: repeated entry, waiting, missed follow-up, information search, unclear ownership, or invisible exceptions. Establish a baseline without inventing a saving. A team can often observe handling time, manual touches, delayed items, or the number of cases returned for correction before it builds anything.

Reject processes that change every week, have no owner, or depend on data nobody understands. Simplifying a form, removing an unnecessary approval, or assigning responsibility may solve the problem without AI. AI is not always needed, and choosing not to automate yet can be responsible when the process is not ready.

• An input clear enough to test against representative cases
• An error that can be detected before an irreversible consequence
• A business owner available to validate rules and exceptions

A hybrid workflow keeps sensitive actions within predictable boundaries. Fixed logic can collect an enquiry, check required fields, and reject unsupported attachments. An AI step can suggest a category or summary. Another rule checks the output against allowed values and sends uncertain or sensitive cases to human validation.

Specify what a model may suggest and what it may actually trigger. Drafting is not publishing. Recommending a category is not deleting a request. Extracting an amount is not approving an invoice. The more costly, public, or difficult to reverse the action, the clearer the human approval boundary must be.

Provide a path that works without the model. If an AI service is unavailable, the workflow can preserve the request, send it to a manual queue, and alert an owner. It should not lose the item or continue with an invented value. This fallback turns an external dependency into a manageable failure mode.

For a Moroccan business, multichannel sales follow-up is a useful example. Fixed rules can normalize the source, create a task, and assign a lead by a known territory or service. AI can suggest intent from a multilingual free-form message, while a salesperson takes over when French or Arabic wording remains unclear.

For invoices, forms, and other documents, deterministic logic can monitor a folder, verify file type, and store an identifier. AI-assisted extraction can propose field values. Amounts, references, and required details should then be checked against the source document and system of record before any accounting entry or payment decision.

For customer requests arriving through email or WhatsApp, AI can prepare a summary or response draft. Rules control the recipient, approved template, and case status. A person validates sensitive replies. This arrangement assists the team without pretending that generated text is a reliable autonomous decision.

List likely failures before the happy path: a missing field, unexpected format, duplicate, API limit, expired credential, model output outside an allowed category, or unavailable approver. For each exception, decide whether the workflow retries, stops, requests correction, or sends an alert. An error message should support recovery without exposing unnecessary data.

Human approval must identify a role and a decision, not appear as a vague sentence in the scope. State who reviews the case, what context they receive, which actions are available, and what rejection does. Where an audit trail is appropriate, preserve the suggestion, correction, and final result so the team can understand system behavior.

Test boundaries with realistic examples, including short messages, French and Arabic variants, incomplete documents, and input that fits no category. Human oversight cannot rescue a poor design if reviewers receive too many alerts or too little context. The review queue must be sized for actual volume.

Inventory the data read, created, transformed, and transmitted at every step. Separate personal data, commercial information, and technical secrets. Apply minimum necessary access, use dedicated service accounts, and document third parties. When personal data is processed in Morocco, review applicable obligations under Law 09-08 and CNDP resources.

A reliable integration identifies the source of truth. If the CRM owns sales status, a spreadsheet should not silently overwrite it. Define identifiers, duplicate handling, timing, API constraints, retry behavior, and alerts. Avoid sending a full customer file to a model when a few cleaned fields are enough for the task.

Define retention and deletion as well. Logs help diagnosis but can contain sensitive information themselves. Decide what must be masked, how long operational context remains useful, and who can inspect it. This guide provides a design framework, not legal advice for a particular organization.

A pilot covers a defined input, a limited user group, and enough time to observe normal cases and exceptions. Keep a reference sample handled with the current method. Compare useful metrics such as correctly routed items, requested corrections, handling delay, integration failures, and the volume escalated to a person.

Success criteria should include quality and operations, not only speed. A fast workflow that creates duplicates or hides errors merely moves the work. Define stop criteria as well: an unacceptable error type, an exception queue the team cannot absorb, or a dependency whose maintenance is disproportionate to the benefit.

At the end of the test phase, choose deliberately whether to expand, revise, return to simple rules, or stop. Preserve decisions, failure examples, and configuration changes. The pilot exists to learn before the workflow affects more customers, data, and teams.

Cost includes discovery, implementation, integrations, subscriptions, model usage, monitoring, exception handling, training, and maintenance. A simple rule can be economical to operate when the process stays stable. An AI step adds a dependency, evaluations, and continuing controls that must be justified by a real need for interpretation.

Identify who owns accounts, scenarios, prompts, code, logs, and documentation. Name who may edit a rule and who approves a model change. An automation without an owner degrades as forms, APIs, and business language evolve. Maintenance is part of the product rather than an optional repair after launch.

Compare alternatives before building: configure the existing tool, connect two systems, improve CRM discipline, simplify the process, or keep a manual checklist. Automation is a means. The desired result is work that is more reliable, understandable, and controllable by the team.