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.

The intended workflow may appear complete, yet staff learn which actions need confirmation, which conversations require another look, and which cases can disappear after being assigned the wrong status. They keep a separate list of work the primary system no longer shows, use a shared communication channel to carry context across handoffs, and compare the recorded outcome with what the customer was told.

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, the balance changes. The system still performs its visible function, but people assume more of the work required to make its output dependable. They preserve relationships the software does not maintain, watch for failures it does not expose, and carry information across boundaries the formal workflow treats as settled.

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. Staff verify routine actions because a confirmation in one interface does not prove that the relevant change occurred elsewhere. They reconstruct conversations because the reason for an escalation was lost during the handoff. They maintain a second queue because cases can leave the official workflow before the underlying problem is resolved. In each instance, the system records an outcome while people supply the reliability, context, or follow-through that the outcome requires.

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 account check is no longer merely a precaution; it is the evidence that the recorded outcome cannot be trusted on its own. The private list is no longer a personal aid; it is the place where unresolved work remains real after the official queue has declared it finished. 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 also be difficult to see because the system continues producing signs of completion. A response was sent. An action was requested. A status changed. A conversation closed. The verbs are all present and appear to be in the correct order. Unfortunately, they do not establish 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 to those gaps provide another part of the evidence. They may reopen cases under a different category, copy information into a shared communication channel, check certain actions in another system, or keep their own list of customers who may need follow-up. These practices reveal where confidence in the formal process ends and additional work begins.

The boundaries 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 purpose is not to treat every discrepancy as a failure or every manual check as unnecessary. A second review may represent appropriate caution. A human decision may be required because the request falls outside the system’s authority. The same action can also combine necessary judgment with verification that became routine only because the systems involved cannot be trusted to agree.

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 changes that request by revealing the conditions under which the work is considered dependable.

Those conditions 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. Staff should not have to remember which actions require confirmation, infer whether responsibility changed, or search several places to understand why a case was closed. Their judgment still has a role, but the system maintains the relationships, communicates its state, and provides the evidence needed to evaluate its output.

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?

The same question applies to human intervention. If a person no longer reviews a category of decisions, has the need for judgment been removed, represented elsewhere, or obscured by a broader definition of routine? Declaring something routine is administratively convenient, but the consequence remains stubbornly attached to whoever experiences it.

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.

Each stage needs a stable boundary. The project should identify what enters the part being changed, what it may decide, what it must produce, and which system owns the result. When one responsibility changes and the surrounding boundaries remain stable, differences are easier to trace.

Some service processes cannot be separated cleanly, but the transition can still be limited by customers, request types, consequences, or time. A complete workflow may need to operate in the new environment while remaining restricted to cases that can be reversed or independently verified. More consequential actions can remain outside that boundary until the organization has 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, the project needs to establish which system is authoritative, which process may alter the record, how corresponding cases will be identified, and who will review discrepancies. 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.

Each stage therefore needs an owner, an exit condition, and a recovery path. The project needs evidence that the new process handles ordinary requests, preserves necessary context, confirms the actions it initiates, and returns uncertain or failed cases to someone able to act. It also needs a way to restore the previous path if the new one creates unacceptable risk.

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.

Staging creates causal clarity. Once one responsibility proves dependable, the next can move without carrying unresolved uncertainty forward.

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 whole customer-service process. Do recorded outcomes agree across the systems involved? Can staff see which actions failed or remain incomplete? Does a handoff include enough context for the next person to proceed? Can a returning customer reopen the practical issue, even if the earlier conversation was marked resolved? Can another employee take over without learning a private sequence of checks?

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.

The distinction matters because automation can make the service process look more successful while transferring its uncertainty. The customer repeats information the handoff lost. Staff verify actions the interface already described as complete. Another department corrects records altered without the context it needs. The work has not disappeared; it has become harder to associate with the system that created it, which is excellent news for the system’s performance report.

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.

A private list may be evidence that the available statuses no longer describe the work. Repeated account checks may show that confirmation cannot be trusted. A shared communication channel full of copied case histories may indicate that context does not survive changes in responsibility. These practices do not automatically identify the solution, but they reveal where the process deserves attention.

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.