How to Build a Remote Onboarding Checklist for a Remote Employee's First 30 Days

A remote onboarding checklist covers four phases: pre-boarding in the week before the start date, day one, the first week, and structured 30, 60 and 90 day goals. The parts that matter most remotely are the ones that happen before the employee logs in. Equipment and accounts have to work on the first morning, a named buddy has to be assigned, and the first two weeks need a written schedule, because a remote hire cannot pick anything up by osmosis. Widely cited research from Brandon Hall Group found that organizations with a strong onboarding process improve new-hire retention by 82% and productivity by more than 70%.

Below is the checklist itself, phase by phase, with the specific items that get skipped most often on distributed teams and the reason each one exists.

The complete remote onboarding checklist

Use this as the master list and assign every line to a named owner before the offer is signed. Onboarding fails on distributed teams mainly because nobody owns it: the hiring manager assumes IT is handling access, IT assumes HR sent the ticket, and the new hire spends day one waiting.

The remote employee onboarding checklist, line by line

The table above is the shape. This is the actual list. Copy it into whatever your team runs onboarding in, delete what does not apply, and put a name against every remaining line. It is deliberately specific, because the vague version of this list is what produces a new hire sitting in silence on Monday morning.

1 to 2 weeks before the start date

• Signed offer and contract returned and filed
• Payroll set up, and state tax registration confirmed for the state the person actually works in, not the state of your headquarters
• I-9 and W-4 issued, with a plan for remote I-9 verification
• Benefits enrollment sent, with the deadline stated in the email
• Laptop ordered and shipped with a tracking number, timed to arrive at least 3 days early
• Peripherals, monitor and any home-office stipend confirmed in writing
• Email account created and tested by logging into it
• Single sign-on, password manager and MFA enrolled
• Chat, video, project management, code or document repositories and any admin tools provisioned with the right permission level
• Access tested end to end by someone who is not the person creating it
• Added to the right chat channels, calendars, mailing lists and on-call or support rotations
• Buddy or onboarding partner named and briefed on what the role involves
• Week-one calendar invites sent so they land before day one
• 30/60/90 day plan drafted by the hiring manager
• Team told who is joining, when, and what they will own

3 days before

• Welcome email with the start time in the new hire's own time zone
• Exactly what to do at 9am on day one, including the meeting link
• Buddy introduced by name, with a note on what to ask them
• Confirmation the laptop arrived and turns on
• Dress code, working hours and core overlap hours stated plainly

Day one

• Live kickoff call with the hiring manager, camera on, not a recorded video
• Every tool logged into and confirmed working, with someone available to fix what is not
• Team introductions, ideally in small groups rather than one large call
• Walkthrough of how the team communicates: what goes in chat, what goes in a document, what warrants a meeting, and expected response times
• One small real task completed and shipped, however minor
• Written 30/60/90 plan shared and read together
• End-of-day check-in to catch anything broken

Week one

• Daily check-in with the manager, short and scheduled
• Product walkthrough, including a session watching a real customer use it
• Meet every person they will work with regularly, one to one
• Codebase, document library or account structure tour
• Security, data handling and compliance training completed and recorded
• First meaningful piece of work shipped: a pull request, a draft, a ticket resolved
• 30/60/90 plan agreed and written down after any adjustments
• Expenses, time off and IT support processes explained
• End-of-week feedback conversation in both directions

Days 8 to 30

• Weekly one-to-ones established as a standing meeting
• First owned deliverable assigned with a real deadline
• Introduced to stakeholders outside the immediate team
• Benefits enrollment confirmed complete before the window closes
• 30 day review against the written plan, with explicit feedback on what is going well and what is not
• Ask directly what was confusing about onboarding, and fix it for the next hire

Days 31 to 90

• Full workload, independently owned
• Included in planning and prioritization rather than only receiving tasks
• 60 day check-in on the plan
• 90 day review, with a clear statement on whether expectations are being met
• Goals set for the next quarter, closing out onboarding formally

Two lines on that list are the ones most often skipped and most often regretted. Testing access with a second pair of eyes catches the permission that looks granted in an admin panel and is not. And asking the new hire what was confusing at day 30, while they still remember, is the only reliable way this checklist improves rather than ossifying.

What should be done before a remote employee's first day?

Everything that requires someone else's action. Ship the laptop far enough ahead that a delivery delay does not become a lost first day, create every account the person needs, and confirm the logins actually work by testing them. Up to 39% of remote employees report that their technology was not properly configured when they started, and that is entirely preventable.

The pre-boarding week is the highest-leverage part of the whole process, because it is the only part that can be finished before the clock starts. Concretely, one to two weeks out:

• Send the signed offer, the contract, and the payroll and tax forms. If the hire lives in a state you have never employed in, start registration now; it can take weeks and it blocks the first paycheck.
• Ship hardware with a tracking number and a delivery date you have confirmed with the employee, not just with the courier.
• Create accounts for email, chat, the password manager, the code or document repository, the CRM or project tool, and the payroll portal. Then log in as the new user and check each one.
• Put week one on their calendar before day one, so the first thing they see when they open the laptop is a plan rather than an empty week.
• Name a buddy who is not the manager and tell that person what the role involves. Microsoft's internal research on onboarding buddies found that new hires who met with a buddy in their first 90 days reported reaching productivity faster than those who did not.
• Write the welcome email: start time, the first meeting link, who to message if anything breaks, and permission to ask obvious questions.

That last point does more work than it looks like it does. A new remote hire will sit stuck for two hours rather than interrupt a stranger, so tell them explicitly that interrupting is the expected behavior in week one.

What does a remote employee do on their first day?

They should finish the day having met the team, used every tool at least once, and completed one small real piece of work. Not a full workload, and not eight hours of recorded compliance videos either. The goal of day one is to convert an abstract new job into a concrete one, and shipping something tiny does that better than any slide deck.

Start with a live call, not an email. Fifteen minutes with the manager at the agreed start time removes the strangest part of a remote first day, which is logging into silence. Walk through the week's schedule, hand over to the buddy, and let the buddy run the tool setup so the new hire practices asking a peer for help early.

Then pick a genuinely small task that touches the real system: fix a typo in the docs and open the pull request, add a note to a live customer record, publish a message in the team channel introducing themselves. It exercises the permissions you set up, which is how you find the one account that silently does not work, and it ends the day with something finished.

Keep the meeting load light. Two or three short conversations spread across the day, with clear gaps, beats a wall of back-to-back introductions nobody will remember by Friday.

In the first week structure beats enthusiasm

Week one is where remote onboarding diverges most sharply from the in-office version. An office hire absorbs the shape of the company by overhearing it. A remote hire absorbs nothing that is not deliberately given to them, so the week has to be written down in advance.

Two habits carry the week. First, a short daily check-in with the manager, ten minutes, just to surface what is confusing before it hardens into a wrong assumption. Second, ask the new hire to keep a running list of everything they could not find or did not understand. That list is the best documentation audit you will ever get, and it expires: after about a month they stop noticing the gaps.

Which points at the real bottleneck. Most remote onboarding pain is a search problem, not a training problem. The answer usually exists, in a handbook, an old thread, a slide from last quarter, and the new person simply cannot find it. Teams that give new hires one searchable place for every internal document cut a surprising amount of week-one friction, because the questions people are too shy to ask get answered without asking.

How long should remote onboarding take?

Plan for 90 days, with the intensive part in the first two weeks. Around the 30 day mark the focus should shift from learning to contributing, by 60 days the hire should be working independently on owned tasks, and by 90 days they should be carrying a full workload. Treating onboarding as a first-week event is the most common and most expensive mistake.

Write the 30/60/90 plan down and agree it with the employee at the end of week one. It does not need to be elaborate: three to five outcomes per stage, each specific enough that both of you can tell whether it happened.

The 30 day conversation is the one people skip and the one that matters most. Around 20% of turnover happens inside the first 45 days, so a check-in at day 30 is your last cheap chance to catch a mismatch, a missing tool, or a manager and employee who have quietly different ideas of what the job is. What you do after those 90 days is a separate discipline with its own levers, covered in our guide to remote employee retention.

What are the biggest remote onboarding mistakes?

The failures repeat across almost every team. They are all cheap to fix and expensive to ignore.

• Treating day one as an IT ticket. If the laptop and accounts are the whole plan, the hire spends week one guessing at norms nobody wrote down.
• No named buddy. Without a peer who is explicitly responsible, questions go to nobody. The manager is not a substitute; people self-censor with their boss.
• Onboarding that ends on Friday. Retention is decided in the first 90 days, not the first five.
• Meeting overload. Twelve introduction calls in two days produces no retained information and a lot of anxiety.
• No first task. A week of reading with nothing shipped leaves a capable person feeling useless, which is the fastest way to lose a good remote hire early.
• Never asking for feedback. The new hire is the only person who can see your onboarding clearly, and only for about a month.

There is also a compliance layer that catches US employers off guard when the hire lives somewhere new. Payroll registration, state income tax withholding, unemployment insurance and required state-specific notices all apply where the employee sits, not where your office is. Sort that during pre-boarding, not after the first payroll run; we cover the practical steps in hiring remote employees in another state.

Make onboarding part of the hire, not an afterthought

The strongest predictor of whether onboarding goes well is whether it was designed before the offer went out. A checklist written the weekend after someone accepts is already late, because the pre-boarding tasks that decide day one, hardware, accounts, payroll registration, a named buddy, all need a week or more of lead time.

So build it once, as a template, and reuse it. The role-specific parts change (a developer needs repository access and a first pull request, a sales rep needs CRM access and a first call review) but the skeleton does not. Then keep the two feedback loops running: the new hire's list of everything they could not find, and the 30 day conversation. Those two inputs will improve the template faster than any amount of planning.

If you are still filling the role, the same principle applies upstream: a clear job post filters out the mismatches that no onboarding process can rescue. Start with our guide to writing a remote job description, then post the role where the whole audience already wants remote work. You can hire remote developers or hire remote sales reps for $199 a month, and see what a listing includes on our remote job posting pricing page.