Connected does not mean operational

In this illustrative 2020 scenario, Maud sees 180 employees connected to the company network. Management celebrates continuity. Yet Louis in Procurement cannot approve an order, Inès cannot access the shared invoice inbox, and Support receives the same access requests through three channels. Connectivity succeeded; work remains interrupted. Remote continuity must be tested through a complete journey from identity to accepted business outcome.

Written in 2026, this retrospective examines the emergency 2020 transition without attributing later products or requirements to that period. Names and volumes are teaching examples. Some activities require physical presence, equipment or local procedures. The leadership task is to identify what can continue remotely, what needs an onsite relay and what must wait.

Select essential flows before opening every access

Maud brings together Payroll, Procurement, invoicing, customer service and operations owners. They identify the next required act, deadline and people able to perform it. Critical user becomes a responsibility: approve an order, reconcile an invoice, handle a complaint or perform an authorised intervention. A person may be critical for one time window. Decision makers and deputies matter as much as bandwidth.

Standard and privileged access are separated. A technician administering equipment cannot simply use the document-viewing route. Security specialists adapt controls rather than leaving a project team to invent general policy. Onsite relay capacity is also checked: who can replace supplies, scan documents or inspect physical conditions? Remote work depending on an already overloaded onsite person merely relocates the dependency.

A completed onboarding route: device to first outcome

StepPractical checkOwner and expected outcome
Establish identity and authority.Manager confirms role, scope, deputy and temporary-access expiry. An urgent-looking email is insufficient approval.The business owner validates need; Identity implements access and records the authorisation reference.
Prepare device and access method.Device meets agreed security conditions; authentication and recovery are tested. Personal devices are not automatically authorised.Support provides the relevant procedure and a recovery channel independent of the access not yet established.
Open applications and documents needed for the flow.Louis opens the order, attachments and approval route, checking shared inboxes, delegation and required signatures.The application owner observes an end-to-end case; missing rights are linked to the blocked step.
Produce an accepted first outcome.A test order is approved and its status confirmed to the next actor. An invoice is not approved solely from an out-of-process screenshot.The business owner observes the result in the system of record and confirms operational capability.
Remove or renew exceptions.Temporary rights have an owner and expiry; device and procedure are reviewed when the emergency ends.Identity and the manager close the exception or justify its incorporation into enduring rules.

Measure successful tasks, not connected employees

Maud separates access obtained, business journey validated and work actually completed. Each measure has its own visible denominator. If 180 employees connect but only 40 test their essential task, 180 operational employees cannot be claimed. Track tasks completed against those required that day, classifying failures by rights, documents, throughput, approval route or unavailable actors.

Support measures time to outcome, not only technical ticket closure. Restored passwords do not necessarily restore approval ability. Sample business confirmations and repeat incidents are reviewed. Test delegation to an absent manager, new starters, suppliers, weak connections and locally stored documents. Testing only with well-equipped IT managers creates misleading assurance.

In practice: the missing authority behind a VPN complaint

Louis reports a slow VPN. Connectivity measures are normal. Ten minutes of observation show him downloading attachments to send to his manager because approval delegation was never configured. Network load is real but caused by a process workaround. Rather than buying capacity first, the business confirms delegation, the application team enables it and Louis replays an order. The original complaint remains in the ticket to explain the changed diagnosis.

Inès has a different problem: two people access invoices but nobody maintains a single work queue. One invoice is processed twice and another stays in a private email. The fallback assigns a case identifier, owner and visible status, with duplicate checks. The selected tool matters less than preserving those elements. A remote team cannot reconstruct work status from scattered private conversations.

Build support that distinguishes different failures

Support categories separate identity recovery, device, network access, application permissions and process errors. The first contact collects operation, time, population and intended outcome before transfer, retaining follow-up responsibility across teams. Escalation states completed tests and missing information rather than merely referring to a supplier. Resolution articles describe the restored task and procedural limits, not just clicks.

Support capacity is checked against start-of-day and deadline peaks. Coverage and deputies are published through a channel blocked users can reach. Business owners handle authority and procedure questions. Technicians do not independently waive approval, and managers do not independently authorise privileged access. This division supports speed without improvising governance in every ticket.

Emergency debt needs an owner and expiry

Temporary accounts, device exceptions, extra licences, paper procedures and tracking files enter a register. Maud records need, owner, affected data, withdrawal condition and possible cost. Authorised exceptions are distinguished from workarounds discovered afterwards. Competent specialists assess security and data protection; programme leadership follows decisions without replacing them. Working for a week does not justify permanent adoption.

Stabilisation prioritises exceptions exposing several flows or preventing handover. Parallel files require reconciliation before deletion; access cannot be removed randomly when the emergency is declared over. Business owners first confirm the lasting route, then technical teams retire fallback. This avoids recreating the outage through premature cleanup. Licence and support costs are reviewed against populations genuinely retained.

Sector differences: physical relay and evidence

Manufacturing and pharma distinguish remote tasks from onsite acts. Operators cannot become everyone's hands; their interventions need priorities, authorisation and traceability. Production-system access follows specialised rules agreed by competent owners. Required batch documents and controls must not move into private channels because preparation is incomplete.

In banking and insurance, access and segregation of duties remain attached to the case: changing location creates no new approval authority. Test deputy arrangements with a refused case as well as an accepted one. In services and public administration, remote employee access must preserve usable service for poorly equipped citizens. Fallback specifies channels, hours and available information. Assess weak connections and tasks unsuitable for video meetings, not only average employee performance.

Turn emergency success into a sustainable service

Maud closes the transition when selected flows have an owner, tested journey, support route and controlled exceptions. Continuity does not require copying every office habit onto a screen. Essential outcomes must remain achievable and controllable, with explicit physical relay where needed. The review separates restored service, remaining degradation and work requiring redesign. This helps management invest in sustainable capability rather than repeatedly funding the same emergencies.

Sources and method

Primary sources checked on 4 October 2026. The year identifies the period being examined; this retrospective was written in 2026. Later documents provide present-day comparisons, not knowledge attributed to that period. People, scenarios and numerical examples are illustrative teaching material, not results of a CYTIZEN engagement.