When a founder is the only person who can move a piece of work, the fastest-looking fix is often to share a login. It feels practical: the operator can enter the tool, send the message, or approve the item. But a shared password usually hides two unresolved questions. What is the operator actually allowed to do? And how will the agency know which person took the action?
Delegation works better when access and ownership are designed separately. The operator should have an appropriate way to reach the work, and the agency should be clear about the decisions that person may make. A credential is not a handoff plan.
This guide is about operating clarity, not a substitute for specialist security advice or a review of your tools and obligations.
Start with the action, not the application
List the action that needs to move. “Give the operator access to the project tool” is too broad. “Update the delivery status, move a task within the agreed sequence, and notify the client contact when the change is confirmed” has a clearer edge.
For each action, ask:
- What triggers it?
- What decision is involved?
- What information is needed?
- What can the operator do without approval?
- What must be escalated?
- What record should show that it happened?
This turns a vague request for access into a bounded operating requirement. You may find that the operator does not need the founder’s full account. They need a specific role, a named contact, a shared project view, or a documented route for a narrow exception.
The agency handoff plan uses the same trigger, decision, context, boundary, and record structure. Add access as one input to the handoff, not as the handoff itself.
Treat named access as part of the operating design
Where a tool supports individual accounts or role-based permissions, use them. Named access makes the operator’s responsibility visible and gives the agency a way to change that access when a role changes. It also avoids turning the founder’s identity into a shared team resource.
Use the minimum level of access that allows the operator to perform the defined action. “Minimum” is not a universal setting; it depends on the tool and the work. The useful question is, “What does this person need to do this handoff?” rather than, “Which permission makes everything convenient?”
If the tool’s permissions are coarse, write down the limitation. A handoff may need to include a second reviewer, a separate communication step, or a decision to keep a particular action with the founder until the workflow changes. Do not pretend the boundary is precise when the system cannot enforce it.
For a small Singapore agency, the tool may be shared across a local team and external collaborators. Be explicit about which people are inside the handoff and which are not. Do not add client data to a test just because the tool makes it easy to copy.
Keep authentication details out of handoff material
Passwords, API keys, recovery codes, payment card numbers, and other authentication details do not belong in a handoff document, chat thread, or general operating ledger. They identify how to enter a system, not what an operator is authorised to decide.
If access is genuinely needed, use the tool’s established account or access-management path and follow the agency’s own security process. If you do not have a suitable process, treat that as an operational gap to resolve deliberately. Do not make the gap invisible by pasting a secret into a document.
The same rule applies to external customer data. A test scenario can usually be written with synthetic or minimised context. Use the least information needed to understand the decision. SOZ itself does not require uploads, credentials, or external customer-data AI for its handoff work; an agency should apply the same restraint to its own materials.
Separate decision rights from tool rights
An operator can have access without having authority. They may be able to edit a project, but still not be allowed to change a commercial commitment. Another person may have authority to approve the decision but not be the person who enters it into the tool.
Write the two layers down:
Decision right: what the operator may choose, approve, or communicate within the defined boundary.
Tool action: what the operator may view, edit, send, or publish to carry out that decision.
Then define the escalation path. If a scope request crosses a boundary, who decides? If the operator is unavailable, who is the backup? If the tool shows an action the plan does not cover, should it wait or move through another route?
This separation prevents the common failure mode where the founder grants broad access but still expects every meaningful decision to return to them. It also protects the operator from being held responsible for authority they were never given.
Test the route with a low-risk scenario
Pick a representative situation and walk through it from trigger to record. Ask the operator to identify the information they need, use the approved access path, make the decision within scope, and leave the result where the next person can find it.
Watch for friction:
- The operator cannot tell whether they are meant to act or only prepare.
- The system gives them more access than the handoff requires.
- The client communication still has to come from the founder’s account.
- The record does not show who decided or why.
- The backup cannot locate the same context.
Each problem is a design finding. Do not solve every finding by adding more permissions. Sometimes the correct fix is a clearer boundary or a different sequence.
The operator readiness test explains how to observe the decision and the record without judging the operator’s personality. The planned founder absence guide shows how to use the route during a real, time-bounded absence.
Review access when the role changes
Delegation is not a one-time act. A person may change role, stop covering an absence, or become the backup for a different area. Add an access review to the same operating rhythm as the handoff review. Remove access that no longer matches the work, and update the decision owner when responsibility changes.
Keep the review proportionate. The objective is not to create a new bureaucracy around a small agency. A short record of the action, owner, permission boundary, and review point may be enough for one workflow. A more sensitive system may require a different process and qualified advice.
Make the handoff legible to the next person
The real test of a delegated workflow is not whether the first operator can act. It is whether a backup can understand the route without borrowing the founder’s identity or memory.
Write the handoff so another person can see the trigger, decision, authority, access path, escalation, and record. Keep secrets in the appropriate access system, not in the prose. Keep personal preferences separate from the decision rule unless they genuinely define the work.
That makes delegation more durable and keeps ownership visible. If the agency is preparing for a larger change, the ownership transition preparation guide explains why clean decision boundaries and traceable operating records matter beyond one absence.
The practical rule is simple: give people a legitimate way to do the work, a clear boundary for the decision, and a record of what happened. Never confuse a password with any of those three things.