AI & Business Operations
What happens when your next caller is an AI agent?
Google’s Call for Me is an early, US-only example. The useful question for a business is what an automated caller may learn or change—and when a person must take over.
8 min read — Altitude IT Operations Team
Your receptionist answers. The caller says: “I’m an AI assistant calling for Sarah. She would like to move her appointment from Thursday to Friday.” The interesting question is not whether the voice sounds human. It is whether your business can handle the request correctly, without giving away information or changing something the caller was not authorised to change.
A limited feature, with a useful operational lesson
Google’s Gemini Help Center describes a feature called Call for Me, which can call businesses to ask about hours, availability, prices and other information, or to book and manage appointments. It can navigate phone menus and wait on hold. As documented on 1 October 2026, the feature is gradually available to eligible adults in the United States: it requires a Pixel 11 with a US SIM, a Google AI subscription, the Public Beta version of Phone by Google, the current Gemini app and an English device language. It can call US phone numbers only.
This is not evidence that UK businesses are already receiving AI calls at scale, nor that this specific feature can call UK numbers. It is an early, geographically limited example of a wider change: software can place a call and make a routine request on someone’s behalf.
Google says the user reviews the number and information the agent will share, then starts the call. Gemini opens by saying it is an AI assistant from Google calling on the user’s behalf on a recorded line. The user can follow a live transcript, listen, take over, and later review the transcript and recording in the Phone app. Google also says Call for Me cannot make payments or share sensitive financial or personal information.
That disclosure helps a recipient understand what is calling. It does not, by itself, prove which customer the agent represents or grant authority to access an account.
Apply the same rules to the request, not the voice
Start by separating what a caller wants into risk levels. A public question about opening hours is different from a request to disclose a customer’s balance, change account ownership or reset a password. Reception and customer-service teams need an agreed answer for each category, whether the request comes from a person, an app or an automated agent.
Information that is already public
Business hours, a public address, general product availability and published service descriptions can usually be handled through a normal script. The business may choose to answer an automated caller just as it would answer a person. Staff should still use their judgement if the caller pivots from a general question to a customer-specific one.
Routine service changes
Moving a booking or checking a delivery slot may be low risk, but only if the request can be tied to the correct account and the change is reversible. Decide which details are sufficient to identify a booking, whether a confirmation should go to the contact details already on file, and which changes need the account holder to confirm directly. Do not let a caller replace the registered email address or phone number as part of the same unverified interaction.
Account, financial or confidential requests
Changing bank details, transferring ownership, resetting credentials, exposing private records or granting access should trigger stronger checks. The caller’s claim that they are “acting for the customer” is not authentication. Use an established customer portal, a verification method already registered to the account, or a human callback to a known number. Where the request changes money or access, use a second approval if the business’s policy requires it.
Decide what staff may disclose
Write down what reception can answer without checking an account, what requires identity verification, and what must be handled by a named team. A public price list is not the same as a customer-specific quote. A general explanation of your service is not the same as confirming that a person is a customer or sharing their appointment history.
Keep scripts short and useful. For example: “I can give you our public opening hours. To change a customer booking, I need to verify it through the contact details already on the account.” This gives staff a safe next step without asking them to make a legal or technical judgement during a busy call.
Record the outcome and provide a human route
For changes that matter, the business should be able to see what was requested, what was changed, which verification step was used and who approved it. If a phone system, CRM, booking platform or shared mailbox is involved, agree where that record belongs and who reviews it. Keep only the information needed for the business purpose and follow the organisation’s normal retention and privacy rules.
Give staff a simple escalation phrase: “I can’t make that change on this call; the account holder or a member of our team needs to confirm it.” A human hand-off is not a failure of automation. It is a boundary for actions that need more authority or context than the current process can establish.
When both sides use agents
A customer’s assistant may eventually speak to a company’s automated receptionist, which may then update a booking system or CRM. That can be useful for repetitive, well-defined tasks. The measure of success is not whether two systems exchanged fluent messages. It is whether the customer’s intended outcome happened accurately, on the right account, with a record that can be corrected if it did not.
Start with narrow tasks, clear confirmation steps and a way to stop or escalate when the request is ambiguous. Do not connect an automated caller to customer records or account-changing workflows simply because the phone menu can recognise the words. The permissions of the underlying system still determine what the caller can cause it to do.
What should businesses do?
- Which questions can staff answer from public information alone?
- What must be verified before a booking, delivery or account is changed?
- Which actions require the customer, a human operator or a second approver?
- Can staff tell when a caller identifies itself as automated, and do they know the escalation route?
- Are requests and changes recorded in the system that owns the customer relationship?
- Do your scripts protect private information without blocking routine, low-risk requests?
The aim is not to reject every AI caller. It is to make the same business rules apply whether a request arrives from a person, an app or an agent. IT Club has explored what an AI personal assistant might do for its user; the receiving business has a different job—deciding what that assistant may ask it to do.