The scene below is a composite of situations I've seen and heard about in different Lebanese businesses, not a single client, and no name attaches to it. But if you run a customer-facing AI tool in Lebanon, some version of this afternoon is probably already on your calendar, whether you've scheduled it or not.
A twenty-person customer service team in Beirut. It's a Thursday afternoon. Their WhatsApp assistant handles roughly two hundred messages a day, quietly answering questions about orders, hours, and pricing while the humans focus on harder cases. Like many small setups here, it runs through a WhatsApp session linked to a desktop in the office, because that was the cheapest way to get it live. At 2:40pm the power cuts. The router and that desktop share a UPS rated for about forty-five minutes. Nobody checks the clock. By 3:25pm the assistant is offline, the message queue is climbing, and the three staff members who used to handle these conversations by hand were reassigned to other work months ago because the tool made them unnecessary. Nobody in the building has written down what happens next. So nothing happens next. The queue just grows.
Why "It Worked in the Demo" Isn't the Same as "It Worked on a Bad Thursday"
Every AI tool I've seen sold into this market gets evaluated the same way. Someone runs it for a week, maybe two. The internet holds. The power holds. The card on file charges cleanly. The tool answers questions correctly, handles the edge cases reasonably well, and the team decides it's ready. That's a fair test of whether the tool is smart. It is not a test of whether the tool is available.
Availability and intelligence are different problems, and in my work with Lebanese SMEs I've come to believe the second one gets almost all the attention while the first one gets almost none. A tool that answers brilliantly ninety-six percent of the time and disappears without warning during the other four percent is not a reliable tool. It's an intermittent one, and intermittent is a much harder problem to manage than merely imperfect, because staff and customers can't predict when it will happen.
The demo happens in optimal conditions almost by definition. Lebanon's normal operating conditions include scheduled and unscheduled power cuts, mobile and fixed connectivity that can drop for reasons that have nothing to do with your business, and a banking environment where a foreign vendor's card charge can bounce for reasons that have nothing to do with whether you have money in the account. None of that shows up in a pilot. All of it shows up eventually once you're live.
The Five Points Where an AI Tool Actually Breaks in Lebanon
Over repeated conversations with SME owners here, the same five failure points keep surfacing. I think of them as a pre-launch checklist, not because they're exotic, but because almost nobody writes them down before going live, which is exactly why they cause damage when they hit.
- Power. What does the tool actually depend on inside your building? Even when the AI itself runs in the cloud, the linked device, the router, the modem, and the screen your team uses to take over conversations often do not. A UPS may keep the router alive, but does it keep everything else in that chain alive too? How long does that battery genuinely last under real load, not the number printed on the box?
- Connectivity. Is there a tested mobile-data fallback that actually kicks in when the fixed line drops, or does the tool simply queue messages silently and let them pile up unseen until someone happens to check?
- Payment access. Is there a second working card or payment method on file with the vendor, and has it actually been verified to charge successfully, not just added and forgotten? A single declined card can suspend service exactly when you can least afford the interruption.
- Data access. If the tool goes dark, can your staff see the last known state, open conversations, pending orders, and outstanding questions, without the tool itself? Or does that information live only inside a system nobody can currently reach?
- Human fallback. Is there a named person, not "someone," with a short script, whose job it explicitly is to pick up the moment the tool goes down? Do they know it's their job, or did that responsibility quietly evaporate along with their old workload?
None of these five points require an enterprise IT department. They require a written answer, in advance, to five direct questions.
Running the Composite Back Through the Checklist
Go back to that Thursday. Run each of the five points against it and the outcome changes at every step.
Power. If someone had timed the UPS honestly rather than trusting the label, they would have known 3:25pm was coming and planned around a forty-five-minute window instead of discovering it in real time.
Connectivity. Power was the trigger this time, but the connection question still applies: a tested fallback, plus someone watching for the moment the assistant stops replying, would have made the outage visible immediately instead of silently queuing messages that nobody saw climbing.
Payment access. This particular Thursday wasn't a billing failure, but the same blind spot applies: a business that has never verified its backup card discovers that fact at the worst possible moment, usually mid-outage, when there's no time to fix it.
Data access. Even with the tool down, staff with a clear view of open conversations and pending orders could triage by hand instead of guessing which customers were already mid-conversation when the lights went out.
Human fallback. This is where the Thursday scenario actually breaks down. The three people who used to answer these messages were reassigned months earlier. There was no named person with a script, because the job itself had quietly stopped existing. That's not a technology failure. It's a staffing decision nobody revisited once the AI tool proved itself capable on ordinary days.
Test It Before Launch, Not After the First Outage
The good news is that all five points can be tested in a single afternoon, before a real outage forces the issue.
- Cut the connection on purpose, at a time you choose, and time exactly how long the tool keeps functioning and how it behaves once it stops.
- Switch to the mobile-data fallback and confirm it actually engages, rather than assuming it will because it's configured somewhere in a settings menu.
- Charge the backup payment method for a small real amount and confirm it clears, instead of trusting that a card on file will work when it's finally needed.
- Have a staff member try to find the last five open conversations without touching the AI tool at all, and see how long that actually takes.
- Name the fallback person out loud, in the room, and hand them a one-page script, then ask them to read it back to you.
None of this requires new software or a consultant. It requires one afternoon and the willingness to deliberately break your own system while you still control the timing.
The Takeaway
The fix here isn't a better AI tool. Most of the tools already on the market in Lebanon are perfectly capable on an ordinary day. The fix is a written continuity plan built on the assumption that the tool will go dark at some point in its first year, because in this market, it eventually will. Power will cut. A connection will drop. A card will get declined. The only real question is whether anyone in the building already knows what to do when it happens, or whether that afternoon becomes the first time anyone thinks about it at all.
If you want a second pair of eyes on your own continuity plan, or want to run this checklist against your current setup, you can reach me through jonahtebaa.com. For related reading, see what AI really costs in Lebanon once the invoice arrives and the four-question triage for choosing your first AI use case in MENA.
For more on this and related work, see BrianServes, the platform for deploying autonomous AI e-mployees and Webspot, the AI strategy firm in Beirut.
