Cresta and the work that continues after a customer call

On November 2, 2026, Salesforce announced an agreement to acquire Cresta. Closing remains conditional. The proposed combination raises a practical question: how should a customer conversation become reliable work?

The analysis below concerns the design of contact-center AI. It is not a claim that an integrated product already exists or that the transaction has produced savings. A useful assessment begins at the point where speech ends and an operational obligation remains.

A conversation creates a chain of obligations

Consider a hypothetical customer asking to replace a damaged delivery. A fluent agent can acknowledge the problem, describe a replacement and end the call politely. Yet several separate decisions remain: which order is involved, whether the customer is entitled to a replacement, where the new parcel should go, and whether a warehouse accepted the request. A transcript saying that a replacement will arrive is not evidence that any of those steps succeeded.

An implementation therefore needs more than a common customer identifier. It needs a distinction between an expressed preference, an authorized action and a confirmed result. A customer might mention a new address while explaining an earlier problem. Treating that sentence as permission to change all future deliveries would expand the request. Conversely, ignoring it entirely could send the replacement to the wrong place. The system has to preserve both meaning and scope.

A useful task record would connect the request, the policy version applied, the action attempted and the response from the receiving system. When that response is missing, the customer should receive an accurate pending status. An agent that repeats an uncertain write can create duplicate work; an agent that silently abandons it leaves a promise unfulfilled. This is why recovery and reconciliation belong in the service design, rather than being added only after a failed demonstration.

Feedback needs an outcome that can be checked

Cresta's August 3 engineering article describes separate evaluation of an agent's process and its final result, using both model-based and deterministic checks. This provides a useful starting point, not independent proof of deployment quality.

Our proposed extension is to grade service at several time horizons. Immediately after a call, review whether the agent understood the request and stayed within its authority. Later, compare the promised action with the order or account record. After an appropriate interval, check for repeat contacts about the same unresolved issue. These tests answer different questions and should not collapse into a single score.

A short call may indicate successful resolution, premature termination or a customer giving up. A favorable satisfaction response can coexist with a replacement that never ships. If training rewards the easiest observable signal, the system can improve its reported performance while making the underlying service worse. The operational team must decide which evidence can overturn a positive conversation assessment.

Human escalation also needs interpretation. A transfer prompted by a genuine exception can be good performance. Penalizing every transfer creates an incentive to retain cases that exceed the agent's authority. Reviewers should distinguish unnecessary transfers from well-timed handoffs and check whether the receiving employee gets enough context to continue without restarting the customer's story.

Integration changes who must resolve disagreements

Connecting conversation tools with a customer system can make these checks easier to organize. It can also concentrate disagreement: the transcript, policy engine and transaction record may each describe a different state. A shared screen does not decide which source is authoritative.

For the hypothetical replacement, the warehouse record should determine whether dispatch occurred, while the customer request determines the permitted destination. A model-generated summary should not overwrite either. Teams need an owner for mismatches and a route to correct them. Otherwise, the integration merely moves reconciliation from one employee's desktop into an automated queue that nobody owns.

There is also a commercial choice. A buyer may value fewer interfaces and one support relationship; another may prefer the ability to replace the voice layer without rebuilding service records. The right comparison includes migration effort, exportable task history and the cost of reverting a failed release. These are evaluation questions, not findings about either company's current contracts.

Technical connectivity should not automatically expand data use either. Whether a complaint recording can be reused for training, who may inspect it and which fields need masking require separate operational decisions. This is not a conclusion about any particular law. The implementation point is that readable data should not be treated as approved for every purpose.

What would count as evidence of improvement?

The 2025 published study Generative AI at Work found uneven benefits across customer-support workers. It studied assistance to humans, not this acquisition or autonomous voice resolution. Its relevance is methodological: an average should not replace examination of who benefits and which tasks improve.

A buyer could compare equivalent case types before and after a limited rollout, including repeat contacts, reversals and staff time spent correcting errors. Difficult cases must remain in the denominator. If automation takes only straightforward requests, the remaining human queue will become harder; a change in average human handling time would then be a poor standalone verdict. Conversely, improvement on easy requests would not establish readiness for more complex responsibilities.

NIST's voluntary AI risk framework places trustworthiness within system design, use and evaluation. For this setting, our interpretation is that an acceptance decision needs operational evidence and a named owner, not only a model score.

The deal announcement establishes a transaction milestone. The more consequential product milestone would be a service team able to explain, for a disputed case, what the customer asked, what the system was allowed to do, what actually happened and how an error was repaired. Until that evidence is available, integration benefits remain a proposition to test.