GoZupees — Building AI Agents for Tomorrow

88% of AI pilots never reach production. That's not a technology problem. It's a measurement problem. The voice AI industry has been optimising for containment (whether the AI kept the call) instead of resolution (whether the customer actually got what they needed). Those two things are not the same metric, and the gap between them is where most deployments quietly fail. We broke down the math, the failure modes, and what contact centres should actually be measuring in 2026. Worth a read if you're in contact centre ops, CX leadership, or evaluating AI voice platforms right now. Link in the comments. #VoiceAI #ContactCenterAI #AIVoiceAgents #CXLeadership #CCaaS #GoZupees

Everyone watched Google put agents in the search box at I/O. Almost nobody read the line near the end: this summer, Search will call local businesses on your behalf. Read it from the other side of the call. The agent is a patient, scripted caller dialing a hundred competitors at once. The business gets a ringing phone - and most of them aren't built to answer a machine. This edition: the buried line in Google's Search reveal, frontier performance shipped at Flash prices, and why "connect your apps" is a business model wearing a feature's costume.

How many AI tools does your company run? If you're typical: somewhere between 8 and 15. One for summarisation. One for sentiment. One for ticket triage. One for churn prediction. One for email drafts. One for chat. One for forecasting. One embedded in the CRM that nobody asked for. Seven vendors. Seven data models. Seven integration points. Zero shared context. The sentiment tool knows a customer was angry yesterday. The chatbot greeting them this morning doesn't. The churn model flagging their account has no idea about either. Every system making decisions on a partial picture. Every system technically working. The whole thing collectively blind. You don't need more AI. You need less AI on better foundations. The model is a commodity. The data layer underneath it is the moat. Wrote a full piece on why operational intelligence beats AI tool collecting ↓ #EnterpriseAI #AgenticAI #DataStrategy

Average Handle Time is the most overrated metric in customer service. It looks like operational efficiency. It's actually a perverse incentive that trains your agents to make customers angrier. When an agent rushes a customer off the line to keep her AHT down, that customer almost always calls back. Sometimes that day. Sometimes the next week. Sometimes never — they just churn instead. The first call counts toward the agent's AHT. The second call counts toward someone else's. The churn doesn't count anywhere. We review 100% of inbound at several ISPs. The pattern that keeps showing up: a meaningful share of calls flagged "efficient" by AHT are the second or third call in a chain that started days earlier. The agents with longer AHT often have the best first-contact resolution. They take two extra minutes to verify the truck-roll, or read the ticket history. The dashboard punishes them anyway. Stop reporting AHT as your headline KPI. Replace it with five numbers 👉 first-contact resolution, 👉 repeat contact within 7 days, 👉 sentiment trajectory, 👉 effort score, 👉 resolution accuracy. You'll have a higher AHT. You'll also have a lower churn number. The second one is the one that funds the contact center.

In a ISP business, The outage isn't what makes customers leave. The silence is. Here's the timeline of a typical network outage at a typical ISP: What the ISP does: 0 min — Alarms trigger. NOC begins manual triage. 15 min — Engineer correlates alarms. Identifies cause. 45 min — Blast radius mapped. Ticket created. 90 min — Someone decides to send a notification. 3+ hours — Bulk email sent. If at all. What the customer experiences: 0 min — Service drops. Restarts router. Waits. 5 min — Calls support. On hold. Frustrated. 15 min — Calls back. "Any update?" No update. 30 min — Posts on social media. 60 min — Sees other subscribers complaining. Considers switching. The customer found out about the outage before the ISP told them. That's the communication gap. And the data on what it costs is brutal: → 5–10x normal call volume during outage events → 40–60% of those calls are subscribers calling back for updates they never received → Poorly communicated outages increase churn probability by 15–25% → 82% of customers prefer proactive communication during outages → 87% say proactive outreach makes them more loyal A deployment we supported in America showed a 36% reduction in contact centre call volumes during outage events just from notifying subscribers within 30 seconds of fault detection. Not 30 minutes. 30 seconds. And there's a thing called the service recovery paradox: recovering well from a failure can lead to higher customer satisfaction than never having a failure at all. At GoZupees, we close the communication gap automatically. Our platform connects network fault intelligence to subscriber communication in a single automated pipeline. When a fault is detected, the system correlates the alarms, maps every affected subscriber by traversing your live network topology, composes a personalised notification (name, area, nature of disruption, estimated restoration time), and delivers it via the subscriber's preferred channel — SMS, WhatsApp, email, Telegram, voice call, or app push — all within 30 seconds of detection. Then it manages the full lifecycle automatically: progress updates when the ETA changes, restoration confirmation when service resumes, and automated account credits if SLA thresholds were breached. No human drafts messages. No one manually processes rebates. It integrates with your existing monitoring, CRM, and billing systems — no rip-and-replace. Deployment takes days, not months. And you can start in approval-gated mode (one-click confirmation from a NOC supervisor) before graduating to fully autonomous. If your subscribers are finding out about outages from their own experience instead of from you — this is the fix.

Common Knowledge. Wrong. #8 "Build the AI then figure out the use case." This is the most expensive mistake in ISP AI adoption. And it is disturbingly common. It usually starts with a board meeting. Someone has read the McKinsey report. A competitor has announced an AI initiative. The pressure to move is real and the direction is clear: we need to be doing AI. So the mandate comes down. Build something. We will figure out what it does once it is running. What gets built is technically impressive and operationally useless. A voice agent that can handle any question except the four questions customers actually call about. A NOC automation layer that ingests alerts brilliantly but has no instruction for what to do when two alerts conflict. A customer-facing chatbot that understands natural language perfectly and has access to none of the systems it needs to answer anything. The technology worked. The use case was never defined. The deployment failed. Here is the order that actually works. 1. Start with a conversation that happens in your business fifty times a day. Not an interesting conversation. The boring, repetitive, predictable one that your best people are exhausted by. The one where the answer is almost always the same and the only reason a human is involved is because nobody has built the alternative. 2. Write down exactly what information is needed to handle that conversation. Not ideally — minimally. What is the least amount of data required to resolve this correctly 80% of the time? 3. Find where that data lives. Confirm it is readable. Confirm it is accurate enough to act on. 4. Now you have a use case. Now build the AI. This sequencing feels slower. It is not. It is the only sequence that produces something that works in production, generates measurable results in the first 30 days, and builds the organisational confidence to deploy the next agent. Our research on GenAI scaling is unambiguous: fewer than one third of AI experiments move into production. The ones that do share a single characteristic. They were built backwards from a specific operational problem, not forwards from a technology capability. The AI is the easy part. It has never been easier or cheaper to deploy. What remains hard — and what determines whether any of it delivers value — is the clarity of thought that happens before a single line of code is written. What is the decision? Who makes it today? What do they need to make it? How will you know when the AI is making it correctly? Answer those four questions first. Then build. #CommonKnowledgeWrong #ISP #AI #OperationsLeadership #WISP

Your IVR saves about £180,000 a year in deflected agent costs. BUT BUT BUT BUTTTT It destroys £10.5 million in customer lifetime value. That's a 58:1 ratio. We built the model (Because why not ?). Mid-market ISP, 80,000 subscribers, 120,000 calls a month. Their IVR has a 15% abandonment rate and those are the callers who give up INSIDE the menu, before they even reach a queue. Most companies don't track this number. It doesn't show up in queue reports. One company we came across found 18% of calls dying in the IVR. Completely invisible to their contact centre metrics. Total blind spot. More than half those callers never ring back. 3% convert to churn within 90 days. At £1,620 lifetime value each, that's £874,800 in destroyed value. Monthly. Meanwhile the CFO is pointing at the IVR as a cost saving. The most expensive infrastructure in your contact centre isn't the network. It's the phone menu. Full financial model in the article ↓ #CustomerExperience #VoiceAI #ISP #Telecoms

This is the current state of a crisis. A construction crew severs a fibre link at 2:47 PM. 47 downstream devices lose connectivity. 200+ alarms fire simultaneously. In a manual NOC: An engineer sees the alarm wall light up. Starts correlating. Opens a spreadsheet to trace the topology. 25 minutes pass. Creates a ticket. Starts thinking about which customers are affected. Gets pulled into a call. 45 minutes later, somebody suggests notifying customers. An email is drafted. Approved. Sent. By now it's been 90 minutes. The contact centre has been handling 8x normal call volume for over an hour. Social media has three threads about the outage. In an autonomous NOC: Our AI clusters 200 alarms into 1 correlated incident in 3 seconds. Then traverses the topology: 47 devices, 312 subscribers affected — mapped in under 3 seconds. NexOps AI creates a parent ticket with child tickets per zone, auto-categorised by severity. 312 personalised notifications go out via SMS, WhatsApp, or email within 15 seconds of detection. An engineer receives a notification: "Zone 3 fibre cut, 312 subscribers notified, field dispatch initiated." Their job is to monitor, not scramble. Total time from fault to customer notification: < 30 seconds. That's not a feature upgrade. It's a different operating model. We've deployed this across 5 ISP and they are on way to gaining full NOC autonomy. Where are you ?

Common Knowledge. Wrong. #7 "We need to hire AI talent before we can do anything." This belief is understandable. AI feels technical. Technical things require technical people. Therefore: recruit a data scientist, find a machine learning engineer, maybe bring in a head of AI. Then start. The sequencing is backwards. And it is causing ISPs to delay by 12 to 18 months waiting for hires that (even if they materialise) will arrive with no operational context and spend their first six months learning the business before they can do anything useful. Here is what AI deployment in an ISP environment actually requires to start. - Someone who understands which customer calls are most frequent and most repetitive. - Someone who knows which alerts are noise and which ones matter. - Someone who can describe, clearly and specifically, what a good outcome looks like when a customer calls about a billing query. - Someone with access to the APIs or data exports that two or three core systems can provide. None of those people are data scientists. They are your contact centre manager, your NOC lead, your operations director. They already work for you. They have the knowledge that an external AI hire would spend months trying to acquire. The talent gap in ISP AI adoption is not technical. It is definitional. Most operators have not yet done the work of turning operational knowledge into explicit decision logic. That work (deciding what gets automated, what the rules are, what escalation looks like) is unglamorous and unsexy. It does not feel like an AI project. It feels like a process documentation exercise. It is also the single most important thing you can do before deploying any agent. Our 2025 State of AI Infrastructure report found that only 14% of leaders say they have the right talent to meet their AI goals. What that statistic does not distinguish is how many of those organisations are looking for the wrong talent. External AI specialists without domain knowledge consistently underperform internal operators who understand the business and have been given the tools and framework to automate what they already know. The most effective ISP AI deployments we have seen were not led by data scientists. They were led by operations managers who knew exactly which 40 call types represented 80% of their volume and were willing to describe, in plain language, how each one should be handled. That knowledge exists in your organisation right now. You do not need to hire it. You need to extract it. And we are here to enable you utilise it and make AI work in your favour. #CommonKnowledgeWrong #ISP #AI #Talent #Operations

Everyone is talking about AI agents as if they are just better chatbots. That is the least interesting thing about them. The real shift is happening deeper in the stack. AI agents are starting to replace the one layer enterprise software has tolerated for years, but never really loved: middleware. Because traditional middleware can move data. But it cannot understand it. It cannot tell that a billing issue, an open service ticket, and live network degradation are all part of the same customer problem. It cannot decide what matters most. It cannot add context before the next system acts. An AI agent can. That changes far more than integration. It changes how enterprises orchestrate decisions, how AI systems get context, and why so many automation projects have felt brittle for years. The next integration layer will not be built on rules alone. It will be built on reasoning. That is a much bigger architectural shift than most companies realise. We wrote about why the AI agent is becoming the new middleware and what that means for enterprise systems over the next few years. Read the full article below. ↓