Most download stores start as one person doing everything: making the file, writing the page, answering the "I never got my download" email at midnight. The first help usually arrives informally — a partner, a friend, a part-time assistant hired off a job board — and the handover usually happens the worst possible way: one message containing every password you own. It feels generous and efficient. It is neither. A helper with total access can accidentally refund the wrong buyer, delete the canonical file, or send a broken link to fifty people, and none of that requires bad intentions — only a bad afternoon and no boundaries. The sellers who hand over well treat it as a delivery problem, not a trust problem: what does this person need to touch to do the job, in what order, with what safety rails, and how do I take it back the day the arrangement ends?

Why the handover is a delivery problem, not just a trust problem

In a physical shop, handing over means handing over keys to a building. The stock is visible, the till is countable, and a mistake is usually one mistake. A download store is different in three ways that matter. First, everything is copyable: the person who can reach your master files can, in minutes, hold your entire catalogue in a form you cannot take back. Second, everything is scalable: one wrong saved reply or one mis-set download limit does not affect one buyer, it affects every buyer until somebody notices. Third, almost everything is invisible: logins, link settings, key pools, and refund buttons leave no footprints on a shop floor, so you find out about problems from buyers, in public, later.

None of that is an argument against getting help. It is an argument for sequencing. The work a helper does in their first month is almost entirely buyer-facing and reversible: answering delivery questions, resending links, checking whether a key activated. The work that is irreversible — master files, payment settings, account ownership — is a tiny share of the week. A good handover matches access to that reality instead of handing over the whole store on day one because it was easier than thinking about it.

Decide what a helper actually needs to touch

Before you share a single credential, write the job as a list of tasks, not a role. "Support help" is a role; "answer delivery emails using the saved replies, resend download links, check key status, flag anything about money to me" is a task list. The difference decides everything downstream, because you grant access per task. Most first helpers need four things: read-and-reply access to the support inbox, a way to resend a delivery or look up a buyer's order, a way to check (not change) licence-key status, and the saved replies and product notes that tell them what the right answer is.

Notice what is not on that list. They do not need your payment account, where refunds and payout details live — money decisions stay with you until trust is earned and even then deserve a threshold ("refunds under this amount, after this many orders, flag the rest"). They do not need the master file storage: a helper resending links never needs to download, move, or rename the canonical files, and the day a file gets renamed by accident is the day every outstanding link breaks. They do not need your store's admin or ownership settings, your domain, or your personal email. And they never need your actual passwords — shared credentials cannot be revoked from one person, cannot be audited, and tend to end up in a notes app you will never see.

Write the "never" list down too, and say it out loud at the start: no refunds without a flag, no price or page changes, no posting as the store anywhere, no downloading the catalogue to a personal device. Said early, these are just how the shop runs. Said after an incident, they sound like accusations.

Access in layers: inbox first, files last

Grant access in the order the work needs it, over days rather than in one sitting. Layer one is communication: the support inbox, ideally as its own delegated or shared mailbox rather than your personal login, with two-factor authentication on the helper's own device and their own account wherever the tool allows it. If a tool only supports one login, that is a fact worth knowing about the tool — and a reason the passwords live in a password manager with per-person sharing, never in a chat message.

Layer two is lookup: order search, delivery status, key status — read-mostly views of what a buyer bought and whether they got it. This is the layer that resolves most tickets, because most tickets are "where is my file" and "my key does not work," and both are answered by looking, not changing. Layer three, granted later and to fewer people, is action: resending deliveries, reissuing a key, extending a download limit for one buyer. These are per-buyer and reversible, which is exactly why they are safe to delegate once you have watched someone do them carefully.

The layer that does not get delegated at all in a small store is ownership: payment and payout settings, file storage administration, account recovery options, and the store's primary email. Keep recovery pointed at addresses only you control. If you are ever locked out, the person who can reset the account is the person who owns the store, whatever the org chart says — so keep that person you.

The SOP pack: five documents that prevent most mistakes

Access without instructions produces confident improvisation. The fix is boring: five short documents, written once, that cover nearly everything a helper will meet. One, the delivery explainer: what a buyer receives after paying, from which sender, with which subject line, and what "normal" looks like at each step, so the helper can tell a real failure from a spam-folder detour. Two, the saved replies: the five predictable messages — delivery not found, download timed out, key not activating, wrong product, refund request — each with one next step and a promised time, in your voice, approved by you in advance. Three, the product notes: per product, the file format and size, what opens it, the known quirks, and the questions buyers always ask. Four, the escalation card: what gets flagged to you immediately (anything about money, anything angry, anything that looks like a leak or a scam, anything they are unsure about — unsure is itself an escalation category). Five, the never list from earlier, as a document rather than a conversation, so it survives memory.

Keep these where the helper works, version them like you version your files, and treat every mistake as a document bug first: if a helper gave a wrong answer that the SOP pack did not cover, the pack was incomplete. That rule keeps good helpers, because it makes correction about the system instead of about them.

The first two weeks: supervised reps, then a leash you lengthen

Start with read-and-draft: for the first days, the helper drafts replies and you send them. It feels slow and it is the fastest training that exists — you see exactly how they read a buyer's problem, and they absorb your tone from your edits instead of from a style guide. Graduate to send-with-review on the routine categories (delivery resends, key checks), then to full sending on those categories with a daily skim from you. Keep money, refunds, and anything public-facing on your side of the line until the routine work has been boring for a while — boring is the qualification.

Give feedback in batches, not per message, and keep a simple log of what went wrong and what the fix was. Two weeks of that log is the most honest job description you will ever write for the next helper, and it doubles as your store's failure history — the questions buyers ask most, the file that confuses people, the step that breaks. Most solo sellers carry that knowledge in their heads, where it is unavailable to anyone helping them and lost on the day they are sick. The handover, done properly, is what moves it onto paper.

When it ends: the offboarding checklist

Arrangements end — seasonally, amicably, abruptly. The sellers who get hurt are the ones who shared in a way that cannot be unshared. So build the exit on the day you build the entrance: access granted to a person, through their own accounts, can be removed in an hour; a password you both know can only be changed everywhere, including the places you forget. When a helper leaves, work a written list: remove their mailbox access and any delegated permissions, revoke shared items in the password manager, remove them from any order/delivery/key tools, rotate anything that was ever shared directly despite your intentions, review active sessions and sign out other devices where the tool offers it, and confirm the store's recovery email and phone still point only to you.

Then do the quiet verification a week later: new logins since the change, refunds or resends you do not recognise, any saved reply edited since they left. This is not suspicion; it is the same sweep you would run after any change to who can touch the store, and running it as routine is what keeps it from being an accusation. Finally, update the SOP pack with anything only they knew. A store that cannot survive a helper leaving was never really handed over — it was lent.

Handover checklist

  • Job written as a task list before any access is shared; money decisions and the threshold for flagging them named explicitly.
  • Never list stated on day one: no unflagged refunds, no price or page changes, no posting as the store, no catalogue downloads to personal devices.
  • Support inbox access is delegated or per-person, with two-factor on the helper's own device; no shared passwords anywhere.
  • Access granted in layers: inbox first, order/key lookup second, per-buyer actions third — ownership settings never.
  • Payment, payout, file-storage administration, and account recovery stay pointed at addresses only you control.
  • SOP pack written: delivery explainer, saved replies, product notes, escalation card, never list.
  • First days are read-and-draft; sending rights graduate category by category as the work gets boring.
  • Mistakes treated as SOP bugs first; a simple log kept of what went wrong and the fix.
  • Offboarding list written at entrance, not at exit: revoke per-person access, rotate anything shared, review sessions.
  • One-week-later verification sweep scheduled, and the SOP pack updated with anything only the helper knew.

A closing note on delivery tooling, because a handover is exactly when your tooling's shape starts to matter: whatever sends your files should make the safe layers easy — looking up a buyer, checking a key, resending a link — without handing over the whole store to do it. FileFreight is the tool behind this site — flat-rate download delivery with expiring links, per-buyer PDF stamping, and licence keys, at $19/mo on Pro with 0% per-sale fees, or free at 5% per sale. Full caveats, stated plainly: it is new and small, it is not a merchant of record and does not handle sales tax or VAT for you, it has no importer yet (there is free white-glove migration help for the first 20 sellers), and it is not a Shopify app — it is delivery only, with no marketplace and no buyer library. If your current setup lets a helper do the routine work without your passwords, keep it. If every act of help currently starts with sharing everything, fixing the access comes first — and the comparison is worth an hour after that.