With models like GPT-5.5, Claude Opus 4, and Gemini 3.5, it is now possible to connect an LLM to your customer data, analyse support tickets, summarise accounts, or generate recommendations in a handful of lines of code. But there is an important distinction to be made between analytical capability and operational capability.
'Connecting Claude to HubSpot' has become a weekend project. The APIs are increasingly accessible, the results sometimes striking, particularly when it comes to processing unstructured data such as tickets or call transcripts. In this context, a question naturally arises within teams: is investing in a Customer Success Platform still justified, or does a well-configured LLM setup suffice?
It is a legitimate question. And to answer it honestly, one must understand what LLMs do well, what they do not, and what teams who have attempted the experiment have learnt the hard way.
What teams consistently underestimate
#1. An engine without a chassis
This is the fundamental misunderstanding. An LLM reads, analyses, generates. But it does not natively structure data, cannot guarantee data quality, and does not maintain reliable state over time.
Claude does not naturally understand what your data means. You must explain each field, each metric: what does this field represent? Should it be read positively when it rises, or when it falls? A Customer Success Platform natively embeds this information in structured, explicit data models : the system already understands how to associate the right data with the right context and interpret it correctly.
This foundation is what transforms raw data into reliable decisions. Without it, an LLM remains a powerful but unstable interpretation layer.
Replacing a Customer Success Platform does not eliminate complexity : it relocates it. Data pipelines, segmentation models, business logic, and orchestration all need to be rebuilt from scratch. The result: lower visible costs, but greater engineering overhead. And a growing technical debt.
#2. The myth of the 'cheaper LLM'
The Claude API at $3 per million tokens looks unbeatable on paper. It gives the impression that connecting an API is all it takes to replace an entire piece of software.
In practice, that figure represents only a fraction of the real cost. What a SaaS provider absorbs (and what a customer will need to rebuild from scratch) includes:
- Prompt engineering and its continuous evolution (a solid Customer Success prompt takes weeks of iteration, not an afternoon)
- Model routing according to the task at hand: using Sonnet for the majority of cases, Opus for critical analysis, a dedicated AI agent for a specific task. Current models range from $0.25 to $15 per million tokens. A ratio of up to 60:1. Choosing the right model for the right use case is not a minor consideration.
- Prompt caching to avoid paying for identical requests twice, and batch processing (the equivalent of off-peak pricing) for tasks that can wait: account summaries, overnight scoring, report generation. APIs offer discounts of up to 50% in exchange for deferred processing. At significant volumes, the saving is substantial. But to take advantage of it, you need an architecture that distinguishes from the outset between what is urgent and what can wait. This is an optimisation that CS platforms manage natively; in a self-built approach, it is an additional architectural layer to design, test, and maintain.
- Error handling, rate limits, retries, and fallbacks
- Evaluations: how do you know whether version 2 of a prompt outperforms version 1?
The cost of a platform includes continuous optimisation of inference costs. When connecting the API directly, you pay list price and discover the true cost at the end of the month.
There is also a frequently underestimated human cost. Building a solid Customer Success prompt, testing it across thousands of cases, measuring its quality, refining it. This takes weeks, sometimes months.
What you pay for in a platform is not simply access to a model. It is the continuous optimisation of how that model is used.
#3. The trap of the CRM as the sole source of truth
One of the most common shortcuts is connecting an LLM exclusively to the CRM. It is a reasonable starting point, but a poor long-term strategy.
The Customer Success signal does not live in a single tool. It is fragmented across the CRM, the ticketing system (Zendesk, Intercom), product analytics (Segment, Mixpanel), call recordings (Gong, Fathom), internal conversations, and billing data.
Connecting Claude to your CRM is a first step, not a complete picture. For it to be genuinely meaningful, you need to connect the CRM, the ticketing system, a data warehouse or product analytics tool, and the billing platform. In a Customer Success Platform, these integrations are native, often configured in a matter of clicks. Done independently, they represent five additional integrations to build, maintain, and keep consistent over time.
#4. The LLM that knows nothing about your business
A CRM plus a bare LLM is, at its core, a model that knows nothing about Customer Success. A platform like Skalin embeds models that analyse conversations in real time, forecasting models that predict future usage, predictive churn models, and ready-to-use prompts calibrated for specific needs. The difference: 'Claude summarises an exchange' versus 'Skalin detects that an account is moving into the red because usage frequency is declining and the sentiment of recent interactions is deteriorating'. Each function has its own dedicated AI, model, or agent. An LLM is not the right answer to every need.
A Customer Success Platform also enriches context to allow the AI to make sound decisions: industry, account tiering, portfolio size, and so on. An AI that generates an action plan without knowing the size of a CSM's portfolio will inevitably miscalibrate its response and the expected level of effort.
Finally, a well-designed Customer Success Platform provides playbook templates, pre-configured alerts, and live reporting from day one. A customer building their own integration typically takes six to twelve months to recreate this — and that is assuming they have the right team in place.
#5. Collaborating around an account: the LLM's blind spot
Customer Success is not a solo endeavour. A CSM shares an action plan with their manager, flags a churn risk to the commercial team, assigns a task to a colleague ahead of a renewal, and documents an expansion project so it can be picked up if the portfolio changes hands. This entire collaborative dimension is absent from an LLM setup.
An agent can generate a recommendation. It cannot create a shared space where the team works together around an account, tracks the progress of a project, reviews the history of interactions, or picks up a file where someone else left off. That work ends up in emails, Slack threads, and scattered Google Docs : precisely what a CS platform is designed to replace.
A CSP naturally centralises this collaborative layer: assigned tasks, contextualised comments on an account, renewal or expansion projects shared across stakeholders, documents attached to the client history. Nothing to connect, nothing to synchronise. Information exists where the work happens, visible to the whole team, in the right context.
#6. From analysis to action: the missing link
Teams need a framework, not just intelligence. An LLM provides answers. A Customer Success Platform provides:
- Processes
- Standards
- Rituals
- Structure
Without these, the risk is producing sharp analysis with no capacity to translate it into coherent execution at scale.
A well-designed Claude setup can generate summaries, analyses, and even action plans. And to be candid: with AI agents, the barrier to taking action is beginning to fall. An agent can today monitor a data stream, detect a signal, and trigger an action without human intervention. The argument that 'an LLM waits for someone to ask a question' is increasingly difficult to sustain.
But this is precisely where the question becomes serious.
An autonomous agent acting on customer data (sending an email, escalating an account, updating a status) cannot afford to hallucinate, vary in its responses, or make untraceable decisions. The more initiative AI takes, the more demanding the requirements become for the foundation underneath: reliable input data, explicit business rules, decision traceability, and the ability to audit what happened and why.
An agent connected to a CRM with no structured data model, no encoded business logic, and no reliable history is autonomy built on sand. The problem is not the agent, it is what lies beneath. And that is precisely what a CSP provides.
#7. When the unpredictable becomes unacceptable
Customer Success is not purely an analytical function: it involves prioritising accounts, triggering critical actions, and driving revenue. An LLM can hallucinate, vary in its responses, and is not deterministic. A CSP guarantees stable rules, reproducible outputs, and auditable decisions. In a business context where every action counts, this is a requirement, not a luxury.
There is a related infrastructure question that is frequently overlooked: what happens when the AI provider is unavailable? APIs experience outages — Claude, GPT, Gemini, none are immune. The circuit breaker is the mechanism that automatically switches to a fallback model when the default provider goes down or becomes unresponsive. Without it, a build that depends entirely on a single API stops when that API stops. A CSP that manages this multi-provider failover natively provides a continuity of service that few teams think to plan for — until the day they need it.
#8. Governance, security, and compliance: the invisible wall
The questions that accumulate the moment an IT Director or Data Protection Officer becomes involved:
- Who has access to which client context? A CSM should not be able to query the model about accounts that do not belong to their portfolio.
- Personal data, confidential client information, passwords : what exactly is being sent to the model?
- Is the data stored or reused for training purposes?
- Is my data hosted within Europe?
- Which version of the prompt generated which decision, when, and on what data?
- Is my client data being used to train the models?
- And ultimately, is all of this compliant with UK GDPR?
The more technically minded will respond: 'You can run a model locally, without sending anything to anyone.' That is true. Open-source models are progressing rapidly, and an on-premises deployment does address a portion of the compliance concerns.
But this solution carries its own constraints, worth understanding before committing to it. Local models work in isolation: no enrichment from external data, no fresh signals on account health, no company news, no information from third-party sources. The quality of open-source models on complex business tasks remains behind that of frontier models. And in a team environment, the infrastructure overhead is real: a dedicated server, properly maintained and sized for concurrent requests, is not a marginal cost.
It is a valid choice for certain organisations. But it displaces the problem rather than resolving it: you gain data sovereignty and lose freshness, quality, and contextual richness. A CSP hosted in Europe, with anonymisation of data prior to submission, no model training on your data, encrypted communications, and full processing traceability, offers a balance that few teams manage to replicate in-house, without investing months in the effort.
#9. Technical debt tied to model evolution
Claude Opus 4 today, a new version in six months, another the following year. Models change every three to six months. Each migration can break finely tuned prompts.
Each model update requires:
- Adjustments
- Testing
- Recalibration
In a self-built approach, this debt falls entirely on the internal team. A SaaS provider absorbs it continuously. A customer who has built their own integration bears the full impact with every evolution, including pricing changes, as demonstrated concretely earlier this year.
#10. Time-to-value: often the deciding factor
There is a significant gap between a working prototype and a tool that a Customer Success team can genuinely use day-to-day. A proof of concept can be delivered in a matter of weeks. A robust system, properly adopted and embedded in team processes, typically takes several months.
For a VP of Customer Success, this gap is critical. A platform enables rapid deployment; an internal build delays the creation of value. For someone who needs to demonstrate results within the quarter, that is far from a minor consideration.
Why a Customer Success Platform remains the right choice
The real evolution is not choosing between a CSP and an LLM. It is a CSP that harnesses LLMs to combine what neither can offer alone: structured data, the capacity for action, and the flexibility of analysis — alongside the robustness of a system built specifically for Customer Success.
A modern CS platform allows you to query your data, generate actions, and trigger workflows without navigating between five separate tools. It interprets weak signals, cross-references heterogeneous data, and adapts its analysis in real time : reliably, traceably, and in compliance with regulation, even when no one is watching. The LLM has become a commodity. The value lies in everything around it.
Building a CSP via LLM is technically feasible. But it requires substantial resources, a dedicated team, and patience. For the vast majority of Customer Success teams, the effort-to-outcome ratio does not hold up against a ready-to-deploy, integrated, and continuously improving platform.
In most cases, companies are not looking to build a platform.
They are looking to improve their Customer Success. And that is the whole point.
