Business Automation Consultant, Lebanon

Designing automations that tolerate outages

Integration pages on this site cover how data moves reliably between systems during outages; see my system integration page for Lebanon. Automation has a related but separate problem. It runs workflows, schedules and reminders that people depend on, and when one of those quietly fails, staff assume the work was done.

The design principles I apply in Lebanese settings:

• Catch-up over precision: a scheduled job that missed its time runs as soon as the system is available, and its output says when it actually ran.
• Offline capture: forms for cash counts, receipts or deliveries that save on the device and submit when the connection returns, each record carrying a unique reference.
• Persistent requests: approval requests that remain open and keep reminding until someone acts, rather than expiring during an outage.
• Visible lag: a simple status showing which automations are behind and how many items wait, so managers know before relying on a report.
• Manual fallback: for every automation, a written step for doing the task by hand if it stays down.

Where the cloud is unreachable from one location, some automations may run better on a local server that syncs later. I compare both options for each location, covering backup and who will look after the server, and write the choice down. Testing always includes a deliberate interruption, with the result checked afterward.

Cash variance checks per currency

For restaurant groups, retailers and distributors in Lebanon, the most valuable automation is often the least glamorous: comparing cash counted with cash expected, every day, in each currency.

The process behind it must exist first. Staff count by currency at shift end or route end, record the count on a form or in the point-of-sale system, and hand cash to a central cashier. My process consulting page for Lebanon covers that design. Once it runs, automation takes over the comparison:

1. Counted amounts per currency arrive from the cash count form or the till close.
2. Expected amounts come from recorded sales, collections or delivery settlements for the same period.
3. Differences inside an agreed tolerance are logged; larger ones create a task for the outlet manager or the driver's supervisor.
4. A morning summary shows finance every location's position and any unexplained items carried forward.

Cash paid out from tills for supplies or petty expenses must be recorded with a voucher, or the comparison will show false differences. The same logic applies to payment methods beyond cash, such as cards and transfer services, once their settlements are in the system.

The automation never posts a write-off on its own. It prepares the facts, and a person with authority decides. Over time the record shows where differences come from, which is more useful than any single day's total.

Rate entry, approval and dual-currency reports

Management in Lebanese companies often wants to see results in dollars and in pounds, and the conversion depends on rates that finance has decided to use. When reports are built by hand, someone exports figures, applies a rate in a spreadsheet and circulates the file, and different people end up with different versions.

Automation removes the rebuilding while keeping the rate decision with finance:

• Rate entry: a designated person enters the rate or rates for the day or period in one place, with the source noted.
• Approval: a second person confirms the entry before it is used, and both actions are logged.
• Distribution: once approved, the rate is available to the ERP and reporting tool, and any price list that depends on it is flagged for review.
• Reports: sales, margin, stock and cash reports refresh in both currencies on a schedule and state which rate was applied.

Which rate applies for which purpose is a finance and accounting decision; I design the workflow, not the policy. If no rate was approved, the reports say so rather than reusing an old one without warning. Price lists that depend on the rate should not change automatically; the automation tells the pricing owner that a review is due. For reporting design more broadly, see management dashboards.

Supplier documents in three languages

Supplier invoices and receipts in Lebanon arrive in Arabic, French or English, sometimes on the same page, priced in dollars or pounds, and often as a photo taken on a phone. Keying them is slow, and mistakes in currency are costly.

A captured-document workflow works in stages:

• Documents are sent to a dedicated address or uploaded from a phone, including from outlets with patchy connections, and queued until they arrive.
• An AI step reads supplier, date, lines, currency and totals, and marks fields it is unsure about.
• Validation checks that the currency is stated, the supplier is known, totals add up and an order or receipt exists where your process requires one.
• A person reviews every flagged document, and your staff confirm any Arabic or French content the system has interpreted.
• Approved documents post to the ERP with the original image linked.

The AI never decides currency, VAT treatment or rate. Those come from the document and from rules your accountant sets. Supplier price changes found during matching are routed to purchasing for approval rather than accepted silently.

Personal data on documents, such as employee names on expense receipts, should be handled in line with Lebanese rules on personal data; your legal advisor confirms what applies. Keep the original document and its posting linked for the retention period your accountant specifies. The finance-side picture is on finance automation.

Who builds, who owns, and what stays manual

Native automation features are my first choice because they stay with the data and do not add another server to keep running during outages. In Odoo that means automation rules and scheduled actions; in Zoho, workflows, Deluge functions and Zoho Flow; in ERPNext, workflows and notifications. For tasks spanning several tools, n8n can be self-hosted, which suits firms that want control over hosting, while Make or Zapier suit cloud-only setups. I configure automations at that level myself. Custom code, deeper ERP changes and anything under your implementer's support agreement are built by them or your developers from my specification, and I check the result against agreed test cases.

Because small teams and single developers are common, documentation matters as much as the build. Each automation ends with a runbook, credentials held by the company, an owner and a deputy.

Some steps stay with people: setting rates, approving write-offs, releasing cash payments, accepting supplier price increases and answering customer disputes. Automation gathers the information and records the outcome.

The result is judged qualitatively: cash differences explained the next morning, reports nobody rebuilds by hand, invoices captured in the week they arrive and an exception queue that shrinks after each outage. My wider approach to automation and governed AI is described on the automation service page; other remote services appear on the Lebanon hub.