A customer leaves an instrument at Branch A, specialist work is performed at Hub B and collection is requested at Branch C. To the customer, this is one service. Inside the business, it can become three separate jobs, two unexplained transfers and several people who believe another location owns the next step.
This hypothetical repair network illustrates why putting every location on the same application is only part of the work. Connected operations require a service model that crosses location boundaries while preserving the facts and responsibilities that differ at each site.
The central question is what the network promises as a whole, which locations can perform each part and how responsibility remains clear while the work moves. Start there before deciding which screens, reports or approvals should be identical everywhere.
A branch may be an intake point, a specialist work center, a collection point or some combination of these. Its name and address do not establish which services it can provide. Keep the capabilities and constraints that affect routing explicit and maintained.
In the repair example, Branch A can record the customer’s request and take custody of the instrument. Hub B has the qualified capability to perform the agreed specialist work. Branch C can hold the returned item for collection. None of those facts implies that every employee at every location may diagnose, authorize additional work or release the item.
The service design needs a feasible route through those capabilities. If the specialist hub cannot accept the relevant instrument type, routing a job there does not create capacity. If the proposed collection branch cannot store the item appropriately, offering it as a destination creates another operating problem.
Describe the customer’s requested outcome and the conditions of the agreed service once, then link each location’s work to that shared job. Local tasks can have their own identifiers, but they should not become unrelated customer commitments. A customer should not have to open a second request simply because the business chose to move the work internally.
ISO’s guidance on the process approach explains the importance of a network of interacting processes and assigned responsibility for those processes. That principle is useful here: optimizing a branch’s task does not establish that the connected service achieves its intended result. This is an operational application of the guidance, not a certification claim. ISO process-approach guidance.
The person holding the instrument, the team performing the next work and the person responsible for communicating with the customer may be different. Recording a single “owner” field can conceal that distinction.
Custody answers where the item is and who is accountable for its physical handling under the business’s process. Work responsibility answers who must carry out or resolve the next service activity. Customer-contact responsibility answers who will provide the next meaningful update and coordinate a response if the plan changes.
At one checkpoint, the item may be in authorized transit from A to B, the specialist team at B may own the upcoming assessment, and an advisor at A may remain the customer’s contact. That is not necessarily an inconsistency. It becomes a problem when the system makes the three responsibilities indistinguishable or leaves one unassigned.
Give each responsibility an appropriate transition rule. A transport departure is not evidence of arrival. Arrival at the hub does not mean the specialist work is complete. Completion of that work does not establish that Branch C has received the item or that the customer has collected it.
The business also needs an accountable role for unresolved cross-location issues. This role should be able to coordinate the response without pretending to have every technical or commercial authority. If additional work needs customer agreement, the correct approval remains necessary even when several internal teams are waiting.
Common definitions make the network understandable. “Received,” “awaiting assessment,” “work authorized” and “ready for collection” should have agreed meanings where the same service uses those states. A location should not mark a job ready for collection merely because its own internal task has ended.
That does not require identical activity at every site. An intake-only branch and a specialist hub perform different work. Their screens, evidence capture and staffing needs can differ while their contributions to the shared service remain compatible.
Separate necessary local variation from avoidable workarounds. A different instrument category, storage requirement or supported service can justify a distinct route. A branch’s preference for an undocumented spreadsheet may instead reveal missing functionality or a policy nobody has resolved.
Record the reason for each material variation, its owner and the circumstances in which it applies. Review it when the service or location changes. A temporary workaround should not quietly become an unexplained permanent fork in the operating model.
There is a tradeoff between central consistency and local responsiveness. If every routine decision requires head-office approval, the network may become slow. If local discretion can alter customer commitments or specialist requirements without coordination, consistency becomes fragile. Define the decisions locations may make themselves and the evidence required for decisions that cross those boundaries.
Staff need enough context to perform their part of the service. Branch C may need the item’s identity, collection conditions and relevant customer contact details. It may not need every internal technical note, commercial dispute or unrelated customer record.
Access should follow the person’s role and the relevant job or location relationship. Membership of the same organization is not, by itself, a reason to expose all information everywhere. Test access through search, attachments, reports and exports as well as the main job screen.
Preserve the history needed to explain the route. If the customer changes the collection branch, show the approved change and the work required to implement it. Do not simply replace the destination field while the item is already in transit to the original branch.
People also need an honest view of uncertainty. If the last confirmed location is Hub B and a transfer is expected, display those facts rather than asserting arrival at C. An estimated movement and a confirmed custody event support different decisions.
During a local connection failure, the business may need a controlled fallback to record custody or customer interactions. Define how those records are reconciled when access returns, including conflicts and actions already completed. A shared platform should not make a branch invent its own recovery process during an outage.
A location-by-location rollout test can miss failures between sites. Test the full A-to-B-to-C journey with the staff and operating arrangements that will actually perform it. Include the customer-facing promise, the physical movement, the specialist activity and the final collection conditions.
Then vary the route. What happens if B finds that the requested work is outside its capability? Who contacts the customer if an additional decision is needed? What happens if C is no longer available as the collection point? The purpose is to expose decisions that otherwise disappear between local queues.
Use a case where the same customer has more than one item in progress. The system should not confuse the items, route the wrong one or treat a status update for one job as applying to all of them. Shared customer identity is useful context, but it is not a substitute for item and service-job identity.
Observe the actual effort required to answer a customer inquiry. If an advisor still needs to call two locations to discover who has the item and what must happen next, the connected record may be incomplete even when all interfaces are technically working.
Evaluate the whole service alongside local performance. A branch can improve its apparent completion time by closing its task immediately after sending an item away. That measure should not be mistaken for faster customer resolution. Retain local measures where useful, but connect them to the network’s agreed outcome and unresolved work.
Opening, merging or closing a location changes more than a directory. It can affect service routes, custody arrangements, staff permissions, customer communications and work already in progress. Plan those changes with the same attention given to introducing a new service.
Before a new collection point becomes selectable, verify the relevant capability, staffing, access, training and exception support. A location record created in the system should not automatically make every service available there.
When a branch closes or stops offering a service, identify open jobs, items in transit and customers expecting to use it. Decide where those obligations move and who confirms that the transition is complete. Preserve historical records under their original location identity so reporting and investigations do not rewrite the past.
Assign ownership of the network model. Someone must maintain the relationship between offered services, capable locations and cross-location responsibilities. Otherwise, a once-accurate design becomes a directory of assumptions that no longer match the business.
Connected operations are working when a customer can experience one coherent service across several locations and staff can explain the state of that service without guessing who owns the next step. A common platform supports that result; the explicit operating relationships make it dependable.
