How to give a virtual assistant safe access to your accounts
Delegating a task does not mean handing over control of the whole business. Before providing access, decide which information and actions the work requires. This guide sets out a practical process for agreeing permissions, keeping ownership with you and preparing for changes or offboarding. No access arrangement removes every risk. Platform features differ and change, so check the current controls available in each account rather than assuming that one set of instructions applies everywhere.
Define the task before choosing permissions
Start with the work to be completed, not the account role you happen to recognise. Write down the records the assistant needs to read, the information they may edit and any actions they must not take. A task involving product-copy preparation may not require the same access as publishing a catalogue update or handling an order enquiry.
Separate technical ability from authority. Someone may be able to use a feature without being authorised to use it for your engagement. State the working boundaries in the brief and identify the decisions that must come back to you. This is especially relevant to spending, refunds, customer commitments and changes to ownership or payment information. If a task cannot be described clearly, resolve the uncertainty before granting broader permissions.
Ask whether live account access is necessary
Some assignments can start with a product brief, exported records or a limited set of documents. For example, an initial review may need approved listing text rather than access to every part of a store. Consider whether a preparation-and-review stage would meet the immediate need while you agree the longer-term workflow.
When sharing files, remove information that is not relevant to the assignment. Do not include a full customer dataset merely because it is easier to export than a smaller set. Explain which copy is current and where completed work should be returned. This reduces confusion about versions and makes it easier to review the result before applying a change to the live account. It also keeps the initial enquiry separate from the later access handover.
Review the account's current user controls
Where a platform supports separate users, roles or delegated permissions, inspect the current options and choose access suited to the agreed task. Do not assume that the name of a role tells you everything it permits. Read the descriptions and check which account areas the role exposes before assigning it.
If the controls are too broad or unclear, discuss another workflow. Work may need to remain in draft form for you to apply, or the proposed scope may need to change. Avoid treating uncertainty as a reason to share the primary login. Keep account ownership and recovery information under your control. Confirm how a user's access can be changed or removed so you understand the end of the process as well as the invitation stage.
Keep passwords and authentication out of enquiries
An enquiry form is for describing the work, not transferring credentials. Do not send primary passwords, recovery codes or payment information while asking for a quote. Establish the scope, the identity of the intended user and the access method before any handover. If an initial message contains more information than needed, remove the unnecessary details before sending it.
Keep two-factor authentication under the account owner's control. Where an individual delegated user needs their own authentication setup, follow the platform's current process without transferring your ownership credentials. Agree how access problems will be reported. A request for broader permissions or an authentication change should be treated as a decision to review, not an automatic part of solving an administrative delay.
Put approvals into the workflow
Specify which actions may be completed directly and which should be prepared for review. A draft-and-approve approach can be useful for product claims, customer responses or changes with a financial effect. Describe the approval channel and how the assistant will know that a particular item has been authorised.
Keep the permission to perform a task narrow enough to understand. An instruction to update one approved price should not become open authority to change a pricing strategy. If a request falls outside the agreed boundaries, ask for it to be recorded and returned to you. Make the same distinction for emergency or urgent work. Urgency may change the priority, but it does not explain who has authority to make a business decision.
Share only the information needed for reporting
Agree what a progress report should contain. Usually you need to know what was completed, what remains open and which decision is required next. Include relevant identifiers where they help you locate the item, but avoid copying unnecessary personal information into a second system or document.
Decide where reports and working files belong and who should be able to read them. Keep source records distinct from working notes so an observation is not mistaken for an authorised change. If screenshots are useful, consider what unrelated information they reveal before sharing them. The aim is a report that supports your decisions without becoming an uncontrolled collection of account or customer data. Review that balance when the work or reporting audience changes.
Revisit access when responsibilities change
Permissions that made sense for an earlier task may no longer fit the current workload. Review access when an engagement expands, pauses or changes focus. Compare the actual work with the account areas still available to the assistant, and remove permissions that are no longer needed where the platform allows it.
Do not let a temporary arrangement become permanent simply because no one has revisited it. Keep a simple record of who has access, why it was provided and who approved it. That record can help with a later handover and with questions about an unexpected change. If more than one person works on the account, make responsibility for each task clear so duplicate changes and unresolved questions are easier to spot.
Agree how to report an unexpected event
Discuss what should happen if someone sees an unfamiliar change, receives an unusual access request or suspects information has been shared incorrectly. Identify the person to contact and the information needed to explain the concern. The reporting process should make it possible to raise a question without guessing at its cause.
Keep investigation and account-control decisions with the appropriate owner or specialist. Depending on the event, you may need to review access, preserve relevant records or follow the platform's current support process. Avoid promising that a checklist prevents every incident. Its purpose is to make responsibilities and next actions clearer. Review the process after a concern so any changes are based on what actually happened rather than assumptions about an individual or a tool.
Finish with a documented handover
At the end of the engagement, review outstanding tasks and ensure that the working documents you need are in the agreed location. Identify any items awaiting a decision so they do not disappear when access is removed. Confirm how business information held for the assignment will be returned or handled under the agreed terms.
Remove access that is no longer required and review any remaining sharing arrangements. Keep enough task history to understand completed changes without retaining unnecessary copies of sensitive information. Netlyst92 discusses access, scope and reporting before work begins. If you are considering administrative, Seller Central or customer-support assistance, describe the tasks first and ask for a tailored quote. Do not include passwords or recovery details in the initial message.