Most onboarding advice is about welcome and culture. The part that actually costs money is access: what you grant on day one, and what you claw back on the last day.
An employee onboarding SOP is the written procedure for turning a signed offer into someone who can do the job without supervision. It names who owns each step, what gets set up before the start date, what happens in the first four weeks, and how you know the person is ready.
For a small ecommerce team, most of that document is about access. Which systems the new person gets, at what permission level, granted by whom, and on what day. The welcome lunch is not the part that goes wrong.
This article covers onboarding any role. The support case has its own ramp: ticket queues, macros, brand voice and escalation tiers. That is covered separately and linked below.
Six blocks. Anything else is padding a small team will not maintain.
| Block | What it holds |
|---|---|
| Trigger | A signed offer with a confirmed start date. Not a verbal yes |
| Owner | One named person who runs onboarding, usually not the hiring manager |
| Pre-start checklist | Accounts, hardware, paperwork, and who raises each request |
| Access matrix | Which systems this role gets, at what permission level |
| Week-by-week plan | What they watch, do supervised, then do alone |
| Ready test | One piece of real work, checked. Not a quiz |
The owner field is the one people skip because it feels obvious. It is not obvious the week two people start at once and the hiring manager is on holiday. Name a role, not a person, so it survives that person leaving.
This is where a DTC onboarding SOP earns its keep, and where the generic advice is least useful. Your new hire does not need a laptop and a company handbook so much as they need correctly scoped access to five or six systems that hold customer data and can move money.
Write the access matrix by role before anyone starts, so it is a lookup rather than a judgement call at eight in the morning:
| System | What to decide in advance |
|---|---|
| Shopify admin | Staff permissions are granular. Decide whether the role can issue refunds, edit products, or view payouts. Most new hires need none of the three |
| Helpdesk | Agent versus admin. Whether they can delete tickets or edit macros other people rely on |
| Email and SMS platform | Whether they can send to the whole list, or only build drafts for review. This one has no undo |
| 3PL or warehouse portal | Read-only until they have run the process supervised. A wrong click here moves physical stock |
| Analytics and finance tools | Usually view-only. Rarely needed on day one at all |
| Password manager | Which vaults, and the rule that nothing is ever shared outside it |
Granting admin because it is faster than working out the right permission level. It is faster on day one and it is the reason nobody can answer, six months later, who changed the refund policy or sent the campaign to the full list.
Raise the requests three business days before the start date, not the morning of. Accounts that need a seat purchased, an approval, or a vendor to action something will not be ready otherwise, and a first day spent waiting for logins sets the tone for everything after it.
Try it on one of your own procedures.
Record a process once, AI writes the structured SOP. 3 free SOPs, no credit card.
Keep the structure the same regardless of role, and change what fills it. The progression matters more than the content, because it is what moves someone from watching to working unsupervised.
That last one is the step that pays for the whole exercise. A new hire is the only person who will ever read your procedures with fresh eyes. Every question they had to ask is a defect in a document, and the window for collecting those closes after about a month, once they have learned the workarounds and stopped noticing.
The watch, do, teach progression in full, and why a quiz is the wrong way to check somebody is ready.
The support-specific version: ticket queues, macros, brand voice, and the escalation tiers a new agent needs on day one.
Almost nobody writes this half, and it is the half with real exposure. Every line in your access matrix is a line that has to be reversed, and unlike onboarding, nothing forces the issue. Onboarding fails loudly, when somebody cannot log in. Offboarding fails silently, for months.
Write it as the same list, read backwards:
The contractor case is the one that catches DTC brands. Seasonal support hires and agency freelancers accumulate access across five or six vendor systems over a busy quarter, granted ad hoc by whoever needed them productive that week. If the grant was not written down, the revoke will not happen.
An onboarding SOP rots faster than most documents because it points at more systems than most documents. Every tool in the access matrix is a vendor who can redesign a permissions screen without telling you.
Three triggers for a review, none of them a calendar date:
The ownership problem underneath this. An onboarding SOP with no named owner is the one that quietly grants admin to everybody.
Start with the access matrix. It takes an afternoon, it is the part with real financial exposure, and once it exists the rest of the onboarding SOP is mostly a schedule.
A written procedure for turning a signed offer into someone who can do the job unsupervised. It names the owner, what gets set up before the start date, which systems the role gets and at what permission level, the week-by-week ramp, and the test that says they are ready. For a small ecommerce team most of it is access control, since that is the part with real cost attached when it goes wrong.
Accounts and permissions for every system the role touches, raised at least three business days ahead so anything needing a seat purchase or vendor action is ready. Hardware, paperwork and payroll setup alongside it. The specific decision worth making in advance is permission level per system, because deciding it on the morning produces admin access granted for speed.
About four weeks to unsupervised work on the first process, structured as watch, do supervised, do alone, then widen. That is a ramp rather than a deadline, and it varies by role. What should not vary is the checkpoint: one piece of real work inspected at the end of week three, before anyone declares the person ready.
Onboarding is the whole arc from signed offer to unsupervised work, including access, paperwork, introductions and context. Training is one part of it: teaching a specific process. A team can have excellent training and terrible onboarding, which usually shows up as a competent new hire who spent their first week unable to log into anything.
Yes, and it is the same document read backwards. Every access grant needs a matching revoke, scheduled for the last working day rather than remembered afterwards. Rotate shared credentials the person knew, reassign whatever they owned, and check third-party vendor seats separately, since those are often granted ad hoc and sit outside your main systems.
3 free SOPs to start. No credit card required. See if drift detection keeps your docs honest.
Start for freeI built ReccordSOP after watching too many DTC ops teams lose months to undocumented workflows. These SOPs are battle-tested with Shopify operators running $1M to $50M brands.
Last reviewed September 10, 2026
A new agent's first month sets their ceiling. A documented onboarding is how you raise it.
Most advice on this describes the culture you should build. This is the procedure itself: the steps, the owner, and the one check that tells you training actually worked.
Most VA hires fail at the handoff, not the hire. The 30-day ramp, the order to give tasks in, and what to write down before day one.
We use essential cookies for sign-in and a small amount of analytics to improve the product. Privacy policy.