You leave on Friday. Can the customer run this?
Fieldgate’s pilot goes live Thursday. Your engagement ends Friday. The customer has a long architecture document but no named operator.
The question
You own the transition to customer operations. The service must run after the engagement ends.
- Customer leadOnly your engineer knows how to renew the connector credential.
- On-callWe have never disabled the agent or restored yesterday’s configuration.
- SponsorThe system must keep working after the engagement ends.
“Set the minimum handover conditions and decide whether Thursday’s launch can proceed.”
Not saved by this site. Your browser may restore text when you navigate back.
A strong answer, step by step
Open each step in turn. This is one strong answer, not the only one.
Step 1: Name the operator
What would you do here? Open the move you’d make.
Send the architecture deck
Tempting, but it misses something. A document does not assign authority to renew credentials or stop the agent.
Assign ownership and access
The strong move. The missing responsibility is operational.
See how a strong candidate says it
“I would agree a customer owner and an escalation path before calling this handed over. A document has no authority to renew credentials or stop unsafe work.”
Why it works: The missing responsibility is operational.
Step 2: Prove a recovery
What would you do here? Open the move you’d make.
Demonstrate recovery yourself
Tempting, but it misses something. Your own recovery demonstration does not establish that the customer can recover it.
Let the customer rehearse recovery
The strong move. A successful consultant demonstration does not prove customer capability.
See how a strong candidate says it
“Have the customer owner disable the agent and restore a known configuration in a safe rehearsal. Check that they can identify incomplete jobs without duplicating work.”
Why it works: A successful consultant demonstration does not prove customer capability.
Step 3: Transfer the access
What would you do here? Open the move you’d make.
Share the engineer’s personal token
Tempting, but it misses something. A departing engineer’s personal token creates an identity and rotation dependency.
Use customer-owned credentials and verify alert delivery
The strong move. The system must not depend on a departing person’s identity.
See how a strong candidate says it
“Document credential ownership, rotation and expiry without copying secrets into the runbook. Confirm least required access under the customer’s accounts and test alerts reaching the owner.”
Why it works: The system must not depend on a departing person’s identity.
Step 4: Make a release decision
What would you do here? Open the move you’d make.
Call the handover complete when documents are sent
Tempting, but it misses something. Sending files does not prove that a customer operator can run the live service.
Gate live scope on demonstrated ownership
The strong move. The sponsor asked for a sustainable system.
See how a strong candidate says it
“If the owner cannot operate and recover it by Friday, reduce scope or defer the live step with an explicit support agreement. Do not imply that an untested handover is complete.”
Why it works: The sponsor asked for a sustainable system.
The answer, in short
- Decision
- Handover requires an owner who can operate and recover it.
- Because
- Personal knowledge and untested recovery leave a dependency.
- What would change it
- A successful customer-led rehearsal plus accepted support ownership changes the release decision.
Common traps
- Equating document delivery with operational readiness.
- Leaving the connector on a consultant’s personal account.
Check your answer
- Did the customer accept a named operator and escalation path?
- Did that operator rehearse stopping and restoring the system?
- Did you verify customer-owned credentials and alert delivery?
- Did you reduce or defer live scope if ownership remained unproven?
Last reviewed Nov 10, 2026