Episode 10 · October 1, 2026 · 53 min
AI Can't Do It All | Pethachi Pichappan
With Pethachi Pichappan, Vice President, Information Technology Services at Concentrix
Bob Hansen talks with Concentrix technology leader Pethachi Pichappan about the limits of AI automation. The conversation starts with customer intent and business problems, then examines when AI should answer, when it should prevent a support request, and when a person should take over—with data, guardrails and change management built in.
What you’ll take away
- Define the customer problem before choosing an AI tool or automation target.
- Decide deliberately when an interaction can be automated and when it needs a person.
- Put data quality, security, observability and guardrails into the operating plan.
- Pilot the change, train the people affected, and measure customer effort and business outcomes.
In this conversation
- Customer intent and contact-center experience
- Natural language processing and generative AI
- Human escalation and automation that prevents the need for support
- Data governance, ROI and organizational change
Episode recap
Editorial summary of the conversation, not a verbatim transcript.
Bob Hansen's conversation with Pethachi Pichappan begins with a question behind the episode's title: if AI can automate a process, should it? Pichappan's career gives the question a practical setting. He describes a start in programming and consulting, an early move into management when a complex project needed someone who understood its end-to-end function, and work establishing a delivery operation in India. He later helped build contact-center capabilities. Across those roles, the recurring problem was not how to install more technology; it was how to make operations work better for customers and the people serving them.
Pichappan places the current generative-AI wave in a longer history. He recalls natural-language-processing work in contact centers around 2000, using earlier bots, grammars and systems rather than today's large language models. Modern tools can address a broader range of interactions, but their improved capability does not turn automation into a universal goal. The same questions about a customer's intent, the operating process and the desired result still apply. Leaders must decide which interactions a system can handle well and which would deteriorate if a human disappeared from the journey.
The discussion turns to customer intent. A company should understand what a customer is trying to accomplish, how sensitive the interaction is and whether a person can create more value than a scripted response. Hansen and Pichappan discuss a cautionary experience in which removing a contact center damaged customer experience and led the business to bring it back. They also consider cancellation: a simple automated path might efficiently close an account, but it can miss the reason a customer is leaving and the chance to address the underlying problem. This is not a rule that every interaction needs an agent. It is a reminder that escalation and human contact need deliberate design wherever trust and context matter.
Some of the most valuable automation, Pichappan suggests, happens before a customer ever needs to ask for help. If a business can supply the right information or resolution at the right point in a journey, the customer need not endure an avoidable support interaction. The measure of success becomes reduced customer effort and a better experience, not just the number of calls diverted. Teams therefore need to map the full process, see where the customer experiences friction, identify what AI can resolve, and specify where a person takes over. A clean handoff is part of the product, not an exception to it.
Getting there requires more than a model purchase. Pichappan stresses the quality and availability of the underlying data, information security and guardrails that keep the system inside its intended boundaries. Leaders also need visibility into what an automated system is doing so they can find errors, adjust it and keep responsibility for outcomes. Because tools alter work, an AI rollout is also a people and change-management effort: what jobs change, what new skills are needed, how will staff learn the tools, and how will leaders explain the plan? The conversation favors pilots with defined outcomes over a grand launch that assumes adoption will follow.
Vendor choice and economics enter the same calculation. The right provider must fit the industry and the problem, not just offer an attractive demonstration. Ongoing model-usage costs must be weighed against the actual business result. Pichappan asks leaders to scrutinize whether the provider is accountable for outcomes rather than merely the tool's availability. By the close of the episode, a simple principle has emerged: begin with the customer and the business problem, use AI where it genuinely improves the journey, and preserve capable human help where automation alone would make that journey worse.
