Onboarding a New VP of Operations: A 7-Day Permissions and Access Checklist

Picture this. Your chapter's new VP of Operations started last Monday. The outgoing VP sent them a welcome email with a list of links, a handful of shared document URLs, and a cheerful "let me know if you get stuck." Two weeks later, the new volunteer still cannot pull the membership report, has been locked out of the email platform twice, and is quietly wondering whether they made a mistake saying yes.

This is the single most common failure mode I saw during my years on the PMI Toronto Chapter board. It is not because anyone is lazy or ill-intentioned. It is because access handoffs are treated as a one-time administrative chore instead of a structured onboarding process. The outgoing volunteer is usually exhausted, the incoming volunteer is eager to contribute, and nobody has a written plan for what gets turned on, in what order, and on what day.

The principle this checklist is built around is simple. Access progression should be intentional and time-boxed. Give a new volunteer too much access too quickly and you have a security and audit problem. Give them too little and they cannot do the job they signed up for. A 7-day ramp fixes both, and it gives the outgoing VP a clear runway to shadow, approve, and hand off one responsibility at a time.

Below is the checklist I would hand any chapter onboarding a new VP of Operations. It is framed around ChapterPulse permissions because that is the system I know best, but the operational principles apply to any chapter ops stack. Copy this into your team's Notion, adjust the role names for your chapter, and run through it Monday morning.

Day 1: Identity and orientation

Day one is about making the new volunteer feel like a member of the team and giving them a place to land. The most important outcome of day one is not access. It is context. You want them to know the lay of the land before they are poking around live systems.

Send a branded invite, not a raw link

How you invite someone onto the platform sets the tone for the entire onboarding. A generic "click here to create an account" email from an unfamiliar sender looks like phishing and feels impersonal. A branded invite email with the chapter logo, the inviter's name, and the role they are being invited into signals that this was thought about. In ChapterPulse, invites go out as branded emails automatically when you add someone through the team settings. The platform captures the event in the audit log on the way out so there is a record of who invited whom.

Assign the lowest structural role that works

ChapterPulse has three structural governance roles: owner, admin, and member. Owner is reserved for the president or whoever owns the relationship with billing. Admin can manage the team and most org settings. Member is a regular contributor. For a new VP of Operations on day one, start them as a member. They do not need admin yet. You can promote them later once they have shown they know their way around.

Do a live walkthrough

Book 30 minutes on the same day they accept the invite. Walk them through the sidebar. Show them where drafts live, where reports live, where settings live. Explain what they currently cannot see and why. New volunteers often assume blank screens mean the platform is broken. Telling them "you do not have reports access yet, that comes on day three" turns confusion into a plan.

Day 2: Read-only access to membership and events

Before anyone touches a newsletter or a dashboard, they need a real understanding of the chapter's current state. Day two is about letting them read widely without being able to change anything. This is the cheapest possible way to build context, and it costs the chapter nothing if they open the wrong page.

Grant draft:read and reports:analytics as a sandbox

These two permissions give the new volunteer visibility into past newsletters and top-line chapter metrics without exposing anything sensitive. They can see what communications went out last quarter, how they were structured, what language the chapter uses. They can see member counts and event trends on the dashboard. None of this includes personal information, and none of it can be edited.

Walk them through a recent newsletter together

Pull up the last newsletter in the draft list and read it side by side. Explain why each section exists, who contributed what, and which pieces are recurring versus one-off. This 20-minute exercise is worth more than any written style guide. It shows the volunteer what "good" looks like on your chapter before they are asked to produce their own.

Hold off on PII access

Resist the temptation to turn on member PII or volunteer PII access in week one. A new volunteer does not need names, emails, and phone numbers to understand the chapter. Aggregate metrics and trends are enough for context. PII access is a meaningful permission and should be granted deliberately when there is a real operational reason, not automatically with the role.

Day 3: Reports and analytics

By day three, the new VP has seen enough to start asking good questions. This is the day you equip them to answer some of those questions themselves.

Confirm reports:analytics is working and spend 30 minutes on the dashboard

Sit with them and walk through every tile on the chapter dashboard. What does member count mean at this chapter specifically? How is renewal rate computed? Which KPIs are fiscal-year-based and which are calendar-based? New volunteers usually assume every metric means what it sounds like, and they are often wrong in ways that lead to bad decisions. A guided tour avoids that.

Introduce insights without PII

If your chapter uses the conversational insights feature, show them how to ask questions in natural language and read the results. Insights can answer most board-level questions ("how many events have we run this fiscal year", "what is our attendance trend") without any personal data at all. The permission that gates named lookups (insights:member_pii) stays off for now.

Give them a small homework question

End the day with one concrete question they can answer using what they now have access to. Something like "what were our three highest-attended events last fiscal year?" This turns read-only access into actual practice and gives them something to report back on at the next board meeting.

Day 4: Communications drafting (but not sending)

Day four is the first time the new volunteer can create something. This is a deliberate split. They get draft:edit so they can write, but not draft:send. Writing is where mistakes are recoverable. Sending is where they are not.

Grant draft:edit only

The new VP can now create announcements and newsletters from templates, edit existing drafts, and save their work. They cannot push anything to the email platform. That responsibility stays with the outgoing VP or the VP of Communications until trust is established.

Walk them through the template system and brand

Show them the announcement templates. Show them the newsletter template. Explain where the chapter's brand colors, header image, and footer live in org settings, and why they should not change those without discussion. Point out the asset library so they know where to pull images from instead of uploading one-offs.

Ask them to draft a practice announcement

Assign them a real but low-stakes piece of writing. A thank-you note to last month's event speakers. A reminder about upcoming volunteer opportunities. Anything that would normally take the outgoing VP 20 minutes. They draft it, save it, and the outgoing VP reviews the draft in the tool itself. No send button needed.

Day 5: Volunteer pipeline, if their role touches it

Not every VP of Operations is responsible for the volunteer pipeline. Some chapters split volunteer coordination out to a dedicated VP. If yours does not, day five is when you give the new volunteer visibility into who is applying to help, which roles are open, and what the status of each applicant looks like.

Decide on reports:volunteer carefully

The reports:volunteer permission includes access to applicant resumes and application details. It is meaningful personal data. Grant it only if managing the volunteer pipeline is actually part of this person's role. If they are primarily focused on events or communications, skip it and come back to it later.

If granted, walk through the applicant workflow once

Show them how applications come in, how to read a resume, how to update application status, and what the chapter's policy is on follow-up. Volunteer applicants are often members who care deeply about the chapter. A clumsy first interaction with a new coordinator sours that relationship for months.

Day 6: Settings access, limited

Settings access is where new volunteers most commonly get into trouble. Not because they are reckless, but because they do not yet know which toggles are load-bearing. Day six is the day to give them a guided tour of what exists in settings, while keeping the edit rights firmly off.

Hold back settings:org

Day six is not the day for settings:org. That permission lets someone change chapter branding, footer content, mailing address, integration URLs, and other things that break the chapter's identity if modified without context. That waits until day 14 at the earliest, and only once they have a clear reason to need it.

Do a read-only tour of settings

Walk them through what is in settings even if they cannot edit it. Show them where branding lives, where org config lives, where data sources are configured, where the team roster lives. The goal is that they know what exists so they can ask "can you change this for me?" instead of hunting for it themselves and accidentally breaking something they did not understand.

Day 7: Send privileges and a first solo task

If the week has gone well, day seven is where the new VP earns the send button. They have read the past newsletters. They have drafted a practice piece and had it reviewed. They understand the brand, the dashboard, and the chapter's operating rhythm. This is the payoff.

Grant draft:send

With draft:send, they can now push communications to the email platform. Every send is captured in the audit log with their name on it, which is a feature, not a threat. It means the chapter has a record of who sent what, which is good for transparency and good for learning from mistakes.

Assign a real, bounded first task

Pick a small, low-risk communication and hand it to them end to end. A reminder about an upcoming workshop. An announcement for a newly-published event. The bar is that it is real enough to matter and small enough that a mistake is easy to recover from. Have the outgoing VP review the draft before they hit send, not after. That review is the last shadow step before full independence.

Debrief at the end of day seven

Ask them three questions. What was confusing? What took longer than expected? What did they want access to that they did not have? Their answers are the best possible input for tuning this checklist for the next person you onboard.

What to hold back in week one

A few permissions should never be granted in the first week, regardless of how the volunteer performs. These are the ones where a small mistake has outsized consequences.

billing:manage

Nobody needs to be editing the subscription, seat count, or Stripe configuration in their first week. This belongs with the president or chapter treasurer. Keep it there.

team:manage

The ability to invite, remove, or re-permission other team members is a privileged operation. A new volunteer should not be making access decisions for other people before they themselves have fully onboarded. Hold this until at least week three, and only grant it if their role genuinely requires it.

insights:member_pii and insights:volunteer_pii

These gate named lookups of member and volunteer personal data in the insights tool. There are legitimate reasons to grant them, but not until the volunteer has demonstrated they understand what the chapter uses personal data for and what the boundaries are. PII access is one of those things where the right question is not "can they be trusted?" but "do they need this to do their job today?" Often the answer in week one is no.

settings:data

This one controls the chapter's data source configuration and credentials for the systems the chapter syncs from. Misconfiguring this can silently break nightly ingests for days. Hold it back until the volunteer has seen a full operations cycle.

Why a checklist beats handing them a preset role

ChapterPulse ships with preset permission templates: Full Access, Editor + Analyst, Editor, Analyst, Viewer, and Greeter. These are convenient, and for some roles they are exactly right. A greeter at the check-in desk does not need anything beyond the greeter preset. A VP of Communications who has been in the role for a year is perfectly served by Editor + Analyst.

But a new volunteer is different. They are in transition. Their access needs on day one are not the same as their access needs on day seven or day thirty. A preset is a snapshot. A checklist is a ramp. The whole point of the week-one plan is that it evolves with the person, day by day.

Direct per-permission assignment is what makes this possible. Rather than moving someone from one preset to another and hoping the delta was right, you flip individual permissions on at the exact moment they need them. The audit log captures every change, so if anyone ever asks "when did this person get send privileges?", the answer is one query away.

The mirror: what to do when they leave

The same principle that shapes onboarding should shape offboarding. A volunteer rotating off the board should not have full access one day and zero access the next. That is disruptive for everyone, including the person stepping down, who may still need to answer questions from the incoming VP for a few weeks.

The mirror of the 7-day onboarding is a 7-day wind-down. In the first few days after their last board meeting, revoke draft:send and billing:manage. Leave draft:edit, reports:analytics, and draft:read in place so they can still answer questions and help the incoming volunteer. By the end of the week, revoke everything except draft:read. A week later, remove them from the team entirely. Every one of those steps is captured in the audit log, which means the chapter has a clear record of when access was removed and by whom.

This is not a trust exercise. It is a handoff. The outgoing VP is not a security risk, they are a colleague. Treating offboarding as a graceful ramp instead of a cliff edge keeps institutional knowledge alive during the transition and makes the next onboarding easier.

Run this for every new VP, every year

Chapter boards turn over. That is the nature of volunteer organizations. The chapters that survive that turnover without losing a step are the ones that treat onboarding as a repeatable process rather than an improvised handoff. A 7-day access checklist is one small piece of that, but it is a piece that every chapter can adopt this week without buying anything new or convincing anyone of a big strategic shift. Write the checklist down. Use it on the next person you onboard. Adjust it based on what they tell you on day seven.

If you want to see how ChapterPulse handles the permission model, the audit log, and the branded invite flow end to end, the fastest way is a short demo. We built it for PMI chapters specifically, and the access model exists because this exact checklist is the one we wish we had when we were onboarding new board members ourselves.

Book a Demo