Berkeley Services: How an AI Intake Agent Went Live in Three Days

Every helpdesk call and WhatsApp message at Berkeley Services now goes to Al-Najāḥ, the AI intake agent we built and run for them. It went live three business days after kickoff, on the numbers tenants already knew. In the last 30 days, it handled 777 conversations in English and Arabic and finished 98% of them without a person.

Going live was the quick part. Making it good enough to run the whole helpdesk took months: on its first scored test run, the agent passed only 46% of real call scenarios. In this story, we have tried to show how we closed that gap, what the agent does on every call, and what changed for Berkeley's team.

Who is Berkeley Services, and what was slowing their helpdesk down?

Berkeley Services Group is an integrated facilities management company founded in Dubai in 1984 and part of Germany's Klüh Group. It runs hard and soft services across the UAE for more than 2,800 clients, from airports and hospitals to homes and offices, with a workforce of over 9,000 people.

Berkeley has run its operation on Facilio since April 2024. That CMMS rollout cut client onboarding time in half and put work orders, assets, inspections and SLAs for every client in one place. As Enrico Menzel, Head of Technical Services at Berkeley, put it: "Facilio has been a key enabler in advancing our digital transformation journey."

The helpdesk was still run by hand. Tenants called and sent WhatsApp messages day and night, and a team typed each request in, routed it and chased it. That meant:

• Three touches per job: every request was handled at least three times before a technician saw it.
• Duplicate tickets: 18% of tickets were duplicates, often a tenant calling twice about the same leak.
• A 24x7 desk run by hand: nights and weekends included, every request was typed in, routed and chased by a person.
• A huge, bilingual portfolio: 166 sites, 2,817 buildings and 43,770 spaces, with names tenants say in English and Arabic.

Why could the agent go live in three days?

Because everything the agent needed to know was already in the CMMS. We did not have to build a property list, request categories or a priority matrix. We connected to what Berkeley already had.

Step 1: Join the phone system tenants already use

Berkeley's phones run on 3CX. We connected the agent to it as another line, so all three helpdesk numbers kept working on voice and on WhatsApp. Messages land in the same place as calls, the way multichannel service request intake should work.

Step 2: Load Berkeley's rules from the CMMS

Request categories, priorities, SLAs and the full property list came straight from the CMMS. Berkeley's team agreed the emergency rules and what should always go to a person.

Step 3: Test on real calls, then switch on

We tested the agent against real call scenarios, then switched it on. From then on, every change has been scored against the same scenarios before it reaches tenants.

What were the hardest problems, and how did we solve them?

These are the four problems that took the most work, and what our engineers built to fix each one.

Property names: 43,770 spaces and a misheard word

Speech-to-text often gets building names wrong, and many of Berkeley's names are Arabic. We built a resolver that matches names by how they sound, including Arabic spellings. So a tenant who says the building name their own way still lands on the right property and space.

Silence: answering in under 200 milliseconds

On a phone call, a short pause feels like a dropped line, and the tenant starts saying "Hello? Hello?" So the agent needs to start answering in under 200 milliseconds, and the largest AI models are too slow for that. We host the voice server in the UAE, detect the end of speech faster and use a fast model for the conversation.

Rules: one agent was trying to do too much

Fast models are less clever. When one long set of instructions tried to cover every case, the agent started skipping rules and mixing up steps. We split the work across specialists for emergencies, existing requests and new requests. Each one carries only the rules it needs, so it stays fast and gets it right.

Proof: from 46% to 98% on real call scenarios

The first scored test run passed 46% of real call scenarios. We traced every failure, fixed it at the root and ran the full set again. The agent now passes 98% on average. That test score is separate from the 98% of real conversations it finishes, and the two agree. Every change is still tested against the same set before it goes live. That is how we measure whether an agent is working.

What does Al-Najāḥ do on every tenant call?

It works out what the tenant needs, finds the right place, and either logs a new request, updates an open one or escalates. Every time, in English or Arabic, at any hour. That is what voice AI for facility service desks looks like in practice: no hold music and no voicemail.

• It answers in the tenant's language: on a call or on WhatsApp, day or night.
• It finds the property: even when the name is misheard or said in Arabic.
• It checks for an open request first: if the tenant is calling about something already reported, it updates that request instead of creating a duplicate.
• It sends emergencies to the front: leaks, fires and gas issues skip every question and go to same-day priority.
• It keeps the tenant posted: once the request is logged, the tenant gets updates at every stage, so they do not need to call back to ask.

Here is what that looked like over the last 30 days.

What still goes to a person?

Anything the agent is unsure about. It does not guess on a tenant's behalf. In the last 30 days, that was 16 conversations out of 777.

• Unclear requests: if the agent cannot confirm the tenant, the property or the problem, it passes the conversation to Berkeley's team with everything it has gathered.
• Callbacks: those 16 conversations ended with a callback from the team, with the full context attached.
• Emergencies on site: the agent logs them at top priority, and Berkeley's team handles the response.
• The decisions: who attends, what it costs and when a job is closed stay with Berkeley's people.

What happens when a client's own system has no API?

Logging the request is not always the end of the job. One of Berkeley's clients runs its own FM portal, and every work order had to be entered there too. The portal has no API and sits behind single sign-on, a security gateway and a one-time code.

So Berkeley's team keyed work orders into it by hand, once a day. Each one meant about four screens, ten pop-ups and four approvals, around 120 screens a day. Someone also had to read every request and pick the portal's two levels of sub-category.

We built an agent that does it for them, production-ready in two days. Since 12 October, it has worked like this:

• Near real time: every reactive work order reaches the client's portal within 15 minutes of being raised.
• The judgment call: the agent reads each request and picks the two sub-categories, checked against the portal's own lists, with a safe default if it is unsure.
• Closed with proof: when the work is done, the request moves through the portal's approvals and closes with the after photos attached.
• Signed in on its own: it handles the sign-in and the one-time code, and Berkeley only hears from us if a password changes.

About 99% of work orders go through without a person touching them. That saves about nine minutes per work order, and at full volume Berkeley is on track to get around 150 hours a month back.

How does an AI intake agent compare with a property management answering service?

A property management answering service takes a message and passes it on. An AI intake agent finishes the job: it logs the request in your CMMS, against the right space, at the right priority. It is also how teams close the after-hours maintenance gap without adding night shifts. At Berkeley, 17% of conversations come in between 7 pm and 7 am.

How does Facilio run tenant helpdesks with AI agents?

Al-Najāḥ is our service intake agent, one of our AI agents for facility operations. It runs on top of the CMMS Berkeley already uses, and our forward-deployed engineers built it with Berkeley's team and still run it.

Why it went live in days, not months

What Berkeley sees on Facilio

Al-Najāḥ at Berkeley Services, last 30 days. Read the full helpdesk AI case study.

Berkeley's team still makes every call that matters: who attends, what it costs and when a job is done. The agent takes the typing, routing and chasing.

The bottom line: is an AI intake agent worth it for a tenant helpdesk?

Yes, if your team spends its day typing in, routing and chasing tenant requests, and your cover thins out at night. Berkeley's helpdesk now finishes 98% of conversations without a person, and the agent went live in days, because the property data was already in a CMMS.

A simple first step: count last month's calls and WhatsApp messages to your helpdesk, and how many came in after hours. That is your starting point, and the number we would measure the agent against.

Frequently asked questions about AI intake agents for tenant helpdesks