Unintended Inheritance

A necessary note before proceeding: the automated agent in this example has not been issued speculative equipment, granted imaginary powers, or promoted beyond the abilities currently advertised for it. Customer-service systems now available can interpret requests, consult organizational records, take action, create or resolve cases, and transfer work to a person. Their implementation guidance also recommends safeguards, staged deployment, and human intervention, which is a wonderfully formal way of acknowledging that events may occur. The example is a composite. The machinery is not. (Salesforce, ServiceNow, and OpenAI)

By the time a process attracts scrutiny, the people using it may have been compensating for its limitations for years.

A customer contacts an organization with a request. An automated agent draws on the available records and policies, responds, and marks the matter resolved. The case is now complete in the reassuring sense that one screen says it is.

Before accepting this administrative triumph, a member of staff checks another system to confirm what happened, reviews the conversation for missing context, and adds anything the next person may need to know. If the records disagree, they correct the problem and place the case somewhere it will remain visible.

Only part of that sequence belongs to the system. The rest developed around it, generally without a budget, formal approval, or anyone announcing that a second process was now under construction.

Staff learn which actions need confirmation and which cases can disappear after being assigned the wrong status. A separate list keeps unfinished work visible, while a shared communication channel carries context the system loses between handoffs.

None of this is especially dramatic. That is part of the problem. Complete failure tends to attract attention. Partial success can remain in service indefinitely, provided enough people remember where to stand and what to hold together.

Over time, people assume more of the work required to make the system’s output dependable, even as its visible function appears unchanged.

The process works. It simply requires a modest supporting cast to ensure that its definition of “resolved” eventually corresponds with reality.

When the System Hands Work Back

Some intervention belongs in any mature process. People interpret unusual requests, make decisions that require judgment, and accept responsibility for outcomes a system should not determine alone. The presence of a human step does not by itself indicate that anything is wrong.

The difficulty begins when the system appears to complete work but people must routinely finish, verify, or repair it.

Each accommodation may seem modest. The effort becomes consequential through frequency and dependence. A brief account check repeated across hundreds of conversations is no longer incidental. A private list that prevents unresolved cases from disappearing has become part of the organization’s service process, despite the small administrative inconvenience of officially not existing.

That is when an accommodation stops being a convenience and becomes infrastructure. The organization may still describe these practices as exceptions, but its service process now depends on them.

Age is therefore an incomplete measure of whether a system still fits. A long-established platform may remain dependable with little intervention, while a recently introduced collection of automated services may require constant supervision. Novelty does not prevent drift. It merely gives the drift a newer interface.

The transfer of work can remain hidden behind reassuring signs of completion. Responses are sent, statuses change, and conversations close. None of those signals alone establishes that the customer’s need was met or that the organization’s records agree about what happened.

Not every added check is waste. Comparing a promised action with the resulting account record may provide an independent point of confirmation. Reviewing a conversation before a consequential decision may protect both the customer and the employee responsible for it. Keeping certain cases visible outside the automated queue may reveal a category the system cannot yet recognize.

These arrangements may be inefficient, but removing them without replacing the assurance they provide can make the process less dependable. The workaround is not necessarily the requirement, but it contains one. Before changing it, the next project needs to understand what the added work accomplishes.

Listening for the Requirement

In the customer-service example, the automated agent does more than place another interface between the organization and the customer. It interprets the request, draws conclusions from the information available to it, may initiate an action, and determines whether the matter appears complete. By the time a member of staff becomes involved, several parts of the process may already have occurred outside their view.

Observation therefore becomes more difficult. Watching someone respond to an escalation may reveal how they use the primary interface, but not how the request was interpreted, which information shaped the response, why the system considered the matter resolved, or whether the action it described actually occurred.

Understanding this use case requires following individual cases across those boundaries. What did the customer ask? Which records and policies were available at the time? What did the automated agent say it had done? What changed in the system responsible for the account? When staff became involved, what did they need to verify, recover, or correct before they could proceed?

The differences between those answers are often more revealing than the intended sequence. A customer may return because an action described as complete never occurred. A person may receive an escalation without the earlier conversation or the reason it was transferred. A response may accurately reflect one record while overlooking newer information stored elsewhere. The process has behaved correctly according to several independent definitions of correct, which is how everyone comes to spend the afternoon determining what happened.

Staff responses provide another part of the evidence. Reopening a case under a different category, for example, may be the only way to return unfinished work to someone’s attention. Understanding why that step is necessary reveals more than recording the step itself.

The reasons for intervening may overlap. A review can combine useful judgment with verification the system could perform earlier. A second account check may confirm a consequential change while also compensating for unreliable communication between systems. A shared communication channel may support legitimate collaboration while carrying context that should have remained attached to the case.

The people affected may see different parts of that problem. Customers know whether the apparent resolution addressed what they asked. Staff know where context goes missing and which outcomes require confirmation. Managers may see completion rates without seeing reopened cases or corrections performed elsewhere. Another department may inherit changes without knowing how or why they were made.

Those accounts need to be considered alongside the records themselves. Together, they show what the process actually accomplishes, where people supply the missing assurance, and which conditions a replacement must preserve. Otherwise, one group’s improvement can become another group’s new workaround, and the organizational circle of life continues.

Turning Observation Into a Solution

In this use case, the process needs to maintain more than a conversation. The customer’s request must remain connected to the information used to interpret it, the response they received, any action taken on their behalf, and the current state of that action. If responsibility passes to a person, the reason for the handoff needs to travel with it. If an action fails or the customer returns, the case needs to become visible again.

The original request for change may be framed much more narrowly. The organization may want to replace one service, introduce more automation, or reduce the number of conversations handled by staff. Observation helps establish what the revised process must preserve: enough context to make a decision, confirmation that an action succeeded, and a way to keep unfinished work visible.

Those requirements do not obligate the replacement to reproduce every existing step. They explain what the existing steps have been trying to accomplish.

A new process can maintain a clearer distinction between a response and a result. Sending a message does not establish that an account changed. Requesting an action does not establish that it succeeded. Closing a conversation does not establish that no further work remains, however attractively the status badge may suggest otherwise. Representing those states separately allows the system to show what has happened without requiring staff to infer it from several interfaces.

The process can also preserve the basis for an automated decision. That does not mean recording every technical detail until a simple request acquires a biography. It means retaining enough information for someone to understand which request was interpreted, which policy or record informed the response, what action was attempted, and what the system believed had been completed. When a person needs to intervene, they can begin with the state of the work rather than reconstructing it from the conversational remains.

Responsibility becomes clearer as well. Some requests can proceed automatically within defined limits. Others require approval because the consequence, uncertainty, or exception exceeds those limits. The handoff is not merely a transfer from automation to a person. It is a change in who is authorized to decide what happens next, and the process should make that change visible.

The same reasoning applies to the supporting workarounds. A separate list can disappear once unresolved work remains visible in the primary process. A shared communication channel no longer needs to preserve case history when that history follows the case. A manual comparison can be removed where the system confirms the result directly, while another comparison may remain because independent review is still valuable.

The improvement lies in moving routine coordination out of individual memory and into the process, leaving staff better placed to exercise judgment where it is needed.

Observation may also reveal that the requested improvement addresses a symptom. Staff who repeatedly correct incomplete handoffs may ask for a better summary. If the missing context exists elsewhere but was never attached to the case, a more polished summary may only conceal the underlying separation with better prose. The better response is to preserve the relationship between the conversation, the account, the attempted action, and the reason human attention became necessary.

Deciding Whose Improvement Counts

A customer-service process involving customers, staff, automated services, and several organizational systems does not have one experience to improve.

Reducing the number of questions may make an interaction easier for the customer while leaving the system without enough information to act responsibly. Allowing more requests to complete automatically may reduce visible workload while concentrating ambiguous and emotionally difficult cases among fewer employees. Closing conversations sooner may improve one measure while making unresolved problems harder to find.

These are not reasons to avoid automation. They are part of defining what it should accomplish.

A mature project makes those effects visible before one group’s improvement becomes another group’s new burden. That may require deciding which information must be established before an action can proceed, which decisions need human authority, and which outcomes justify interrupting an otherwise automatic process. It may also reveal that effort cannot be removed so much as placed where it is more useful and less likely to cause harm.

Not every preference can govern the design, and not every familiar action deserves to remain. The aim is to understand the consequence of removing it. If staff stop checking whether an action succeeded, does the system now provide reliable confirmation, or has the discrepancy become the customer’s responsibility to discover? If the separate list disappears, has its purpose been absorbed into the primary workflow, or has the organization only removed the place where unfinished work remained visible?

Calling more decisions routine does not remove their consequences. If human review is withdrawn, the project needs to establish why it is no longer necessary and who remains responsible when the process gets something wrong.

Questions like these keep the change tied to the work instead of the appearance of simplicity.

Changing One Boundary at a Time

Understanding the customer-service process does not remove the uncertainty of changing it. Demonstrations usually follow an intended path. Daily work includes incomplete information, changing requests, interruptions, conflicting records, and actions that fail after an apparently successful response. Reality continues to decline invitations to follow the demonstration.

A staged rollout gives those conditions room to influence the replacement before the existing process disappears. That may mean moving one responsibility at a time. An automated service can begin by retrieving information while staff continue to decide what to do with it. It can draft responses before being allowed to send them. It can classify and route requests before being authorized to change customer records.

For each stage, agree on what the new process is allowed to do, what it must leave to a person, and how its results will be checked. Keeping the surrounding work stable makes differences easier to trace.

Some service processes cannot be separated cleanly, but the transition can still be limited by customers, request types, consequences, or time. The new process might initially handle only requests whose outcomes can be checked and, if necessary, reversed. More consequential actions can wait until there is evidence that the earlier stages are dependable.

Parallel operation can reveal what ordinary testing misses. For a limited period, the old and new processes may interpret similar requests, propose actions, or record outcomes. Differences can expose missing information, conflicting policies, broken connections, and assumptions the new design does not yet represent. The purpose is to learn from those differences while the change remains recoverable, not to create two permanent processes.

Comparison becomes more complicated when both processes can act. A customer record may change while a conversation is still underway. A later request may alter what an earlier one meant. The old and new systems may assign different statuses to the same case or disagree about whether an action succeeded. Before parallel operation begins, agree on which system holds the official record, which process may change it, how the same case will be matched across both systems, and who will investigate differences. Two authoritative systems are otherwise a generous use of the word “authoritative.”

That review determines what happens when testing ends. A difference may reveal a missing requirement, stale information, an integration failure, a later correction, or an intended improvement in the new design. Reconciliation might mean updating the authoritative record, restoring an unfinished case, or accepting a deliberate difference according to defined rules. It should not be treated as a final synchronization in which one system automatically replaces whatever the other contains and everyone agrees to call the result clean.

Someone needs to be responsible for deciding when each stage is ready to proceed. That decision should rest on evidence from ordinary work, including what happens when information is missing or an action fails. There also needs to be a practical way back if the replacement proves unreliable.

Once those conditions are met, the superseded process and its temporary comparison mechanisms should be retired. Otherwise, a cautious transition becomes another source of ambiguity about where work belongs, which status can be trusted, and who remains responsible. Temporary arrangements have demonstrated a remarkable ability to remain temporary for years.

Once one part of the process proves dependable, the next can move with a clearer understanding of what has changed and what still needs attention.

Recognizing Improvement

A replacement can launch successfully and still leave the organization performing much of the same compensating work.

A faster response says little about whether the requested action occurred. A higher automated-resolution rate may reflect fewer routine conversations reaching staff, or it may reflect cases disappearing before their underlying problems are recognized. Fewer visible handoffs can indicate a more capable process while leaving employees to monitor outcomes elsewhere.

Evaluation needs to follow the work beyond the point where the system reports success. Can a returning customer get an unresolved issue addressed without starting again? Can another employee take over without learning a private sequence of checks? Those experiences help establish whether the replacement has removed a burden or merely made it less visible.

Some improvement can be measured through response time, repeated contact, corrections, and unresolved work. Some appears in the changing purpose of human effort. Staff may still review a consequential action, but no longer need to search several systems before they can understand it. They may still examine unusual cases, but no longer spend the same attention proving that routine actions occurred.

A dashboard can count the conversations closed by automation. It may not count the account checks performed afterward, the cases copied into private lists, the customers who begin again through another route, or the corrections absorbed by another department. The measure is not necessarily false. It has simply concluded its investigation at a particularly convenient moment.

The question is not only whether the automated agent answers quickly or completes more conversations. It is whether the organization has less work to do around those conversations before it can trust the result.

If a change saves time in one place by creating monitoring, reconciliation, or waiting elsewhere, the workflow has been rearranged more than improved.

Leaving Better Evidence Behind

No customer-service system remains new. Policies change, responsibilities move, customers raise needs no one anticipated, and staff find ways to address cases the formal process does not recognize.

New workarounds can reveal that the system and the work have begun to separate again. The organization does not need to prevent every informal adaptation, but it should notice when temporary verification becomes routine, when the same category of case repeatedly leaves the official workflow, or when reliability begins depending on knowledge held by one person.

When a service process handles important information, connects otherwise separate parts of the organization, or determines who is responsible for a customer’s request, its documentation should explain why it works as it does, not merely how to operate it. The process should also expose enough of its state for people to understand what happened. Unfinished actions should remain visible, responsibility should be clear, and recovery should not require reconstructing the history of a conversation.

That evidence also needs to include the reasoning behind important boundaries. Future changes should not have to guess why some actions require approval, why certain information must remain connected to a case, or why a closed conversation can still represent unfinished work. Those decisions may later be challenged, but they should not disappear into configuration and habit, where they will eventually be rediscovered as if left by an earlier civilization.

Unintended inheritance cannot be eliminated because organizations will continue learning things their systems were not designed to know. What people build around those systems should be treated as evidence: sometimes of avoidable burden, sometimes of useful judgment, and often of a requirement that has never been properly expressed.

The goal is not to preserve every way people learned to compensate for the old process. It is to make less of the work depend on remembering where that process could not be trusted.