Google Connected Apps: start with one action.

I keep coming back to a simple question when I read an AI announcement: what can a customer finish that they could not finish before? Google's Connected Apps Platform, announced on 28 October, is interesting to me because it puts that question close to the product. A conversation could lead to an action inside a business's service.

My view: start with one action you can explain, measure and recover when something goes wrong. For a service business, I would rather see one dependable appointment request than a demonstration that promises to run the whole customer journey.

What Google announced

Google has opened a preview of a platform for bringing app capabilities into Search and the Gemini app. Its 28 October announcement describes a shared route for developers to register, test and submit an integration, choosing which of those surfaces to support.

The announcement says access is opening in phases, with more developers and markets to follow. I would check eligibility before quoting a delivery date to a client in Dubai. A preview announcement is useful planning information; it does not confirm access for every UAE business.

My take: the useful unit is a completed task

I see this as a reason to sharpen the service behind an interface. If a customer asks for a viewing, what counts as success? A request sent to a broker, a provisional slot, or an appointment accepted by both sides? Those are different promises. I would write that distinction down before choosing any AI tool.

My preferred first experiment would let a customer check available consultation slots and request one. The system would show exactly what was requested and what still needs confirmation. I would keep payment, negotiation and changes to customer records outside that first experiment. This is the workflow I would propose for a 3tf pilot, rather than a claim about an integration we have already launched.

The same thinking runs through my approach to AI integrations: define the task, the permitted data and the person responsible for exceptions. The model's name matters less to me than whether a customer and a colleague can understand the result.

Prepare the service before the connector

Google's developer overview describes remote MCP servers and an Android path through AppFunctions. MCP is a protocol for exposing tools and data to an AI application. The overview also points developers to OAuth 2.1 for authorising access. I would choose an integration path after checking the business's existing systems and Google's current requirements.

Before that, I would prepare a small, reliable source of truth: service names, appointment duration, opening hours, Dubai time zone, cancellation terms and live availability. An elegant conversation cannot fix two calendars disagreeing about the same slot.

I would also make each tool's response unambiguous. “Request received” should carry a reference and a clear status. “No availability” should return an honest alternative. If the connection fails, the customer needs a route to a person and enough context to avoid starting again.

The first test I would run

I would agree the acceptance criteria with the person handling enquiries, then use a test calendar and fictional customer details. My checklist would include:

• The normal request: a customer selects a free slot and sees the correct date, time zone and confirmation status.
• The repeat request: a retry does not create a second appointment or a second CRM record.
• The changing slot: another booking takes the slot before confirmation; the customer gets a useful response.
• The interrupted connection: an authorisation or network failure does not appear as a successful booking.
• The handoff: a colleague can find the request, understand its history and take responsibility.

For that pilot, I would record successful requests, duplicates, failures requiring staff help and the time needed to resolve them. I would compare those results with the existing booking flow before deciding whether the new route deserves a wider rollout. I would also agree a stop condition, such as any unexplained duplicate, and a way to disable the integration without losing incoming requests.

The website still has a job

I would keep the public service page clear and usable on its own. People and browser agents need readable service details, real links, labelled controls and a visible next step. Search visibility and a Connected Apps integration solve different parts of the journey; neither guarantees that Google will recommend a business.

For 3tf, I would connect this work to the same follow-up discipline described in our website-to-CRM guide. A booking channel is only valuable when the right person receives the request and acts on it. My earlier Gemini agent article gives another starting point for choosing a limited business task.

Which single action would you trust an AI assistant to complete for your customer today? I would start with that answer, then work backwards to the data, permissions and evidence needed to make it dependable.

Sources and publication date

Published 29 October 2026. I checked Google's Connected Apps announcement dated 28 October and its developer overview on 29 October. Product statements above are attributed to Google; the proposed pilot, checks and assessment are my recommendations. Availability and requirements can change during preview.