What is the minimum viable week-one programming calendar for a paid community?

The minimum viable week-one programming calendar for a paid community has three slots. Slot 1 is the Day 0 onboarding DM: sent automatically when a new member joins, it delivers a structured introduction prompt (“Tell us your name, what you work on, and one specific thing you want to get better at this month”) and a single goal-selection question (two or three options) that determines the member's channel track for the Day 3 nudge. The only job of the Day 0 DM is to produce one post in the introductions channel within 24 hours of join. Slot 2 is the Day 3 conditional nudge: sent only to members who have not yet posted an introduction. The tone is not a reminder about a missed checklist item — it is a lower-friction restatement of the invitation (“even a one-liner is fine”) with a direct link to the most active channel for the member’s stated goal track. Personalisation using the Day 0 goal-selection response is what separates a high-converting Day 3 nudge from a generic reminder. Slot 3 is the weekly async community thread prompt: a single question posted in the main channel on a consistent day each week, with the operator’s own reply as the first example response. New members encounter this prompt during their novelty window (days 0–7), when it produces higher reply rates than at any other point in their membership. These three slots are sufficient to produce first-week post rates of 45–60% and peer-connection rates of 40–60% in communities that run them consistently.

How many events should a paid community run in week one?

A paid community should run zero mandatory events and zero scheduled live sessions in week one for new members. Optional live events — webinars, coffee chats, community calls — consistently underperform for new members in week one relative to their performance in week two or three, for a structural reason: new members in week one do not yet have enough context about the community to evaluate whether attending a specific event is worth their time. The evaluation cost (does this event apply to my goal? will the other attendees be people I can learn from? is this the right moment to show up?) is higher than the perceived benefit for a member who has not yet formed a peer connection or posted anything. Operators who schedule welcome webinars, community tours, or coffee chats in week one typically see attendance from 10–20% of new members — and even among attendees, event participation without prior async activation produces an observer experience, not a participation experience. The right timing for optional live events is week two or week three, after at least one async touch (an introduction post or a reply to the weekly thread prompt) has already been completed. At that point, the member has a mental model of the community, has been seen by at least one peer, and can evaluate the event as a deepening opportunity rather than a first-impression risk. The programming that produces first-week activation is exclusively async: Day 0 DM, Day 3 conditional nudge, and weekly thread prompt.

What is the peer-connection rate and how do I track it?

Peer-connection rate is the percentage of new members who receive at least one reply to their introduction post from another member (not the operator or community manager) within 24 hours of posting. It measures whether week-one programming is producing community engagement — peer-to-peer replies — rather than only operator-to-member exchanges. A community where the operator replies to every introduction within an hour may have a 100% response rate but a 0% peer-connection rate, which is the wrong outcome: operator replies are better than no reply, but they do not produce the peer-to-peer dynamic that predicts month-three renewal. Healthy peer-connection rate for a community running a weekly async thread prompt is 40–60%. At-risk: 25–40%. Below 25% is a structural problem. To track it manually: at the end of each week, list every introduction post made by new members who joined in the past 7 days. For each post, note whether it received at least one reply from a non-operator member within 24 hours. Count the introductions that met this criterion and divide by total introductions in the week. For calculation, only count replies from members who are not the operator account or a designated community manager account. A reply from the operator that is then followed by a peer reply within 24 hours counts as a peer-connected introduction; a reply from the operator with no peer reply does not. The intervention when peer-connection rate is below 40%: identify the top 5–10 most active members and establish a standing weekly practice where each commits to replying to at least one new-member introduction per week — a peer-welcome rotation, not a formal buddy system, since buddy systems create assignment dependencies that fail when the buddy is unavailable.

What is the novelty window in paid community onboarding?

The novelty window is the 5–7 day period immediately following a new member’s join date during which the community occupies a structurally elevated position in their attention hierarchy. It is not loyalty or commitment — it is curiosity driven by the act of having paid for access. During the novelty window, new members are more likely to open Slack without a notification, more likely to explore channels unprompted, and more likely to post in response to a thread prompt than at any subsequent point in their membership. After the window closes, the community competes for attention on equal terms with every other workspace, newsletter, and tool in the member’s daily workflow. The practical implication: week-one programming that runs during the novelty window (days 0–7) produces higher conversion to first post than the identical programming sent in week two or three. A weekly thread prompt that a new member encounters on day 5 will receive a reply at approximately 2–3× the rate of the same thread prompt encountered on day 18. This is why the minimum viable week-one programming calendar prioritises async formats that new members encounter automatically during their first week (the Day 0 DM fires on join; the weekly thread prompt runs on a fixed day, so new members who join during the week encounter it within 0–7 days) rather than events scheduled at fixed future dates that fall outside the novelty window for most new cohorts. The novelty window is also the mental model formation window: the programming that runs before it closes determines whether the new member forms a participatory mental model (this community is a place where I contribute) or a broadcast mental model (this community is a place where I read). Once the broadcast model is formed, it is very difficult to reverse with subsequent programming.

Week-One Programming Reference Card

Week-one programming for paid communities — three programming types, minimum viable calendar slot specs, wrong-pattern failure modes, two-metric measurement reference, and novelty window guide

This page is a structured reference card for paid Slack community operators who want the programming types, calendar slot specs, wrong-pattern failure signals, and measurement benchmarks in scannable table form. It covers: a three programming types comparison table (onboarding automation, structured async, optional live) with operator effort, scale profile, when to add, and expected outcome metric for each; a minimum viable week-one calendar table with trigger, format spec, condition, and expected output for each of the three slots; a wrong week-one programming patterns table with four patterns, what each looks like, why it underperforms, the failure signal to watch for, and the fix; a two-metric measurement reference table (first-week post rate and peer-connection rate) with definition, healthy benchmark, at-risk threshold, intervention, and measurement method; and a novelty window reference table showing how member attention level, right programming type, and most common mistake vary across the 0–7 day window and after day 7. For the strategic reasoning behind the week-one programming framework — including why week one is structurally different from every other week, how the novelty window determines which mental model new members form, and how to sequence months 2–3 programming once the week-one baseline is working — see the companion post: Week-one programming for paid communities: the minimum viable calendar. This card is for the operator who understands the reasoning and needs the specs and thresholds in quick-reference form.

TL;DR

Run three programming slots in week one: Day 0 DM (structured introduction prompt + goal-selection question), Day 3 conditional nudge (sent only to non-posters, goal-specific, lower-friction), and weekly async thread prompt (same day each week, one question, operator’s reply as the first example). Do not run mandatory events, buddy systems, or multi-step onboarding quizzes before these three are working. Measure first-week post rate (healthy 45–60%; below 40% triggers Day 0 DM audit) and peer-connection rate (healthy 40–60%; below 25% triggers peer-welcome rotation). All three programming slots must run during the novelty window (days 0–7) — async formats that new members encounter automatically during their first week produce 2–3× higher first-post conversion than the same formats encountered in week two.

Three programming types comparison table

Week-one programming for paid communities falls into three types. Each type does a different job, requires a different level of operator effort, scales differently as the community grows, and is appropriate at a different point in the new member’s tenure. The minimum viable week-one programming stack combines type 1 (onboarding automation) and type 2 (structured async) only; type 3 (optional live) is added in week two or three, after async activation has already occurred. Operators who start with type 3 or who mix all three in week one produce the “too many events” failure pattern described in the wrong-patterns table below.

Type	What it does	Operator effort	Scales without operator time?	When to add	Expected outcome metric
Onboarding automation	Sends a structured sequence of direct messages to new members at fixed intervals from join date: Day 0 welcome DM with introduction prompt and goal-selection question; Day 3 conditional nudge to non-posters with goal-specific lower-friction re-invitation; Day 7 scorecard with a summary of what the member has done and a specific next step. Sets the first-action expectation and creates two additional recovery touchpoints for members who miss the Day 0 prompt.	High setup (write the three DM templates, configure trigger logic in Slack app or Workflow Builder, test delivery for both “posted before Day 3” and “not posted by Day 3” conditions). Near-zero recurring effort once configured — runs automatically for every new join regardless of community size.	Yes — fully automated after setup. Scales from 5 to 5,000 new members per month without additional operator time. The only recurring maintenance is updating DM copy when benchmarks indicate a slot is underperforming (Day 3 nudge copy audit is the most common maintenance task).	Before launching the community, or at the first session after deciding to implement structured onboarding. This is the baseline that all other week-one programming builds on. Do not add type 2 or type 3 until type 1 is configured and confirmed to be delivering DMs to every new join.	Activation rate: the percentage of new members who complete all three Day 0–7 steps (intro post, goal stated, goal-track channel joined). Healthy: 35–50% with structured automation. First-week post rate (indirect): automation creates the conditions; the Day 0 DM prompt design is the primary driver of whether the first post happens.
Structured async formats	Recurring community posts that give all members — including new ones — a low-friction moment to contribute alongside established members. The canonical example is the weekly thread prompt: a single question posted in the main channel on a consistent day each week, with the operator’s own reply as the first response modelling expected length and tone. Puts new members in the same thread as established members without requiring either party to coordinate in advance.	Low recurring effort (write one prompt question per week, post it, add the operator’s reply immediately). No setup beyond deciding on a day, time, and channel. Cannot be fully automated without losing the freshness and topic-relevance that make the format work — the question must be current and specific to the community’s core topic each week.	Partially — the posting and operator-reply step requires manual execution each week. As the community grows, established members begin replying without being prompted, which reduces the operator’s burden to produce the “second reply” that creates the thread dynamic. Below 100 members, the operator typically needs to tag one or two specific members each week to seed the reply chain. Above 200 members with healthy engagement, the thread self-sustains after the operator’s initial post.	From week one, as a complement to onboarding automation. New members encounter the weekly prompt during their novelty window (days 0–7) if their join date falls within the 7 days before the scheduled prompt day. The format is more effective at producing peer connections than onboarding automation alone because it puts new and established members in the same thread simultaneously.	First-week post rate: the percentage of new members who post at least once in any channel in their first 7 days. Peer-connection rate: the percentage of new-member introduction posts that receive at least one non-operator reply within 24 hours. The weekly thread prompt directly drives both metrics by creating a public, low-social-risk post occasion that new members can join without requiring a dedicated introduction.
Optional live touchpoints	Events, calls, or sessions that new members are invited but not required to attend. Formats include welcome webinars, community Q&A calls, coffee chats, and topic-specific workshops. They produce a higher-quality peer-connection experience (real-time dialogue, visible faces or names) than async formats — but only for members who already have enough context about the community to evaluate whether attending is worth their time. For members who have not yet posted or received a peer reply, live events produce an observer experience, not an activation experience.	High recurring effort (schedule, promote, host, follow up). Not appropriate as week-one infrastructure because the effort is not proportional to the activation outcome for new members who have not yet formed a peer connection. Optional live touchpoints are most effective as a month-two or month-three retention mechanism after the async baseline is working.	No — live sessions require operator scheduling, facilitation, and follow-up regardless of community size. Attendance does not scale linearly with community size; large communities require breakout formats or rotating cohorts, which compound the facilitation cost. Do not use live events as the primary week-one activation mechanism if the operator cannot sustain the facilitation cost at scale.	Week two or week three at the earliest, after at least one async activation touchpoint (introduction post or weekly thread prompt reply) has already been completed by the new member. Introducing live events before async activation inverts the sequence: the member has no peer context to bring to the event and typically leaves without a connection. After async activation, a live touchpoint deepens an existing relationship rather than bootstrapping one from zero.	Not a week-one primary metric. In months 2–3, the right outcome metric for optional live events is 30-day contribution rate (the percentage of members who post at least twice in their first 30 days, excluding intro posts). Members who attend a live event in month 2 after async activation in week one have significantly higher 30-day contribution rates than members who attend a live event in week one without prior async activation.

The sequencing principle. The three programming types work best in order: type 1 (automation) sets the first-action expectation; type 2 (async) creates the peer-connection opportunity; type 3 (live) deepens the connection that async already established. Operators who skip to type 3 before type 1 and 2 are working produce high-effort programming that converts at the rate of type 0 (no programming) for new members, because the peer-connection foundation that makes live events valuable is not yet in place.

Minimum viable week-one calendar — slot specifications

The three slots below are sufficient to produce first-week post rates of 45–60% and peer-connection rates of 40–60% in communities that implement them consistently. The “Condition” column specifies whether the slot fires for all new members or only for a subset (the Day 3 nudge fires only to non-posters). The “Expected output” column describes the specific behaviour the slot is designed to produce — not a general engagement goal but the single action that defines success for that slot.

Slot	Trigger	Format spec	Condition	Expected output
Day 0 DM — entry action	Immediate on workspace join. Sent automatically by a Slack app (not Workflow Builder — Workflow Builder sends fail silently if the new member has not engaged with the workspace in the preceding 7 days, which is always the case for brand-new members). Fires within 60 seconds of join event.	Three elements only: (1) structured introduction prompt: “Tell us your name, what you work on, and one specific thing you want to get better at this month” with a direct channel link to the introductions channel; (2) goal-selection question: “What is the primary thing you want to get from this community?” followed by 2–3 options matching the community’s goal tracks (e.g., “A: Grow my subscriber count / B: Improve retention / C: Launch a new tier”); (3) one closing line: “Reply with your choice and I’ll point you to the right channels.” Do not include: community feature lists, event calendars, resource links, community history, or values statements. All of those belong in a separate “getting started” resource; adding them to the Day 0 DM buries the two actions the member needs to take.	All new members, on every workspace join. No exclusion conditions. If a member rejoins (cancelled and rejoined), the Day 0 DM fires again — do not suppress it for returning members, as their goal-selection may have changed.	One introduction post in the introductions channel within 24 hours of join. The goal-selection response (A, B, or C) is collected in the DM reply thread and stored for the Day 3 nudge personalisation. Success: a 24-hour introduction-post rate above 45%. If below 45%, the most common cause is that the first step (the structured introduction prompt) is too high-friction — asking for 3–5 sentences about professional background rather than name + current work + one goal. Simplify to the three-element format above.
Day 3 conditional nudge — recovery intervention	72 hours after join date, checked against posting status. Fired automatically by the same Slack app. The trigger check: has this member posted at least one message in any public channel (excluding DMs with the app) in the 72 hours since their join date? If yes: do not send (member has self-activated). If no: send the Day 3 nudge. The condition check must be confirmed from the Slack API member activity endpoint, not from the app’s own DM log — a member may have been active in channels without having replied to the Day 0 DM.	Four elements: (1) opening line that acknowledges the delay without judgment: “Hey [name] — no rush on the intro, whenever you’re ready.” (2) goal-specific reference: “I see you’re interested in [goal-track from Day 0 response] — there are a few members working on similar things.” If the member did not reply to the goal-selection question on Day 0, use the community’s primary goal track as the default. (3) lower-friction re-invitation: “Even a one-liner works — [channel link] is the place.” (4) one directional link: the most active channel for the member’s goal track, not the general introductions channel. Sending the nudge to the same introductions channel the Day 0 DM linked to produces lower conversion than linking to a goal-specific channel where the member can see relevant conversation already happening.	New members only, and only those who have not yet posted in any public channel at the 72-hour mark. Members who have posted are excluded regardless of whether they completed the full activation sequence (intro + goal-selection + goal-track channel join). The nudge is for non-posters only — sending it to members who have already posted is the second most common Day 3 nudge failure mode (after generic copy).	One introduction post within 24 hours of receiving the nudge (i.e., within 96 hours of join). The post may be in any public channel — the nudge’s goal is to produce a first post, not necessarily in the introductions channel. Success: a Day 3 nudge response rate above 30% (3 in 10 members who receive the nudge post within 24 hours). If below 25%, audit the copy: the most common failure is the opening line starting with “Just a reminder” or “We noticed you haven’t posted yet” — both are judgment-signalling phrases that reduce response rate. Replace with the non-judgment framing above.
Weekly async thread prompt — ongoing post occasion	Posted manually by the operator in the main content channel on the same day each week (typically Monday or Tuesday in the operator’s primary time zone), within the first 2 hours of the workday. Consistency of day is more important than consistency of time within the day — members develop a low-level expectation of the weekly prompt on “Monday” rather than “Monday at 9 AM,” and posting variance of 1–2 hours does not affect reply rates, while posting on a different day of the week breaks the pattern expectation.	Two elements: (1) the prompt question — one open question directly relevant to the community’s core topic, written so it can be answered in 2–4 sentences without requiring preparation or expertise that only senior members have. Format that works: “This week’s question: [specific challenge or decision in the community’s domain] — what has worked for you?” Format to avoid: “What is everyone working on this week?” (too broad, produces vague replies) or “What do you think about [specific recent event/tool]?” (too narrow, excludes members who don’t have an opinion on that specific topic). (2) the operator’s own reply, posted immediately after the thread-starter as the first response, modelling the expected length and depth. The operator’s reply should be 3–5 sentences: a direct answer to the question with one specific example or number. Longer operator replies suppress peer replies by setting a bar that most members feel they cannot match.	All members, every week, not just new members. The thread runs permanently as a weekly community rhythm. New members who join during the week encounter the most recent prompt within their novelty window (0–7 days from join), which is why this format produces disproportionately high first-post conversion for new members relative to the same prompt encountered in week two. If no new member has replied to the prompt within 48 hours of posting, the operator tags one or two members whose goal-track matches the prompt topic and asks for their specific take. This personal tag serves as a direct invitation that other new members can observe, reducing the social cost of replying for members who have not yet established themselves in the community.	Peer-connection rate: the percentage of new-member introduction posts (or any first posts by new members) that are followed by at least one reply from another member (not the operator) in the same week. The weekly thread prompt indirectly drives peer-connection rate by putting new members in a thread alongside established members who are also replying — a new member who replies to the weekly thread is, by definition, participating in a thread where established members will see and can respond to their post. Success: peer-connection rate above 40% in weeks where the weekly prompt is posted. If the prompt runs every week but peer-connection rate stays below 30%, the issue is that established members are not replying to the prompt (indicating the prompt questions are not compelling for the existing membership, not just for new members). Vary the prompt topic by goal track for 4 weeks to test which topics generate the most established-member replies.

Wrong week-one programming patterns — failure modes and fixes

The four patterns below are commonly implemented in week-one programming and consistently underperform relative to the three-slot minimum viable calendar. Each one looks reasonable in planning (it seems to add engagement opportunities) and underperforms in execution (it adds complexity without improving the two outcomes week-one programming is designed to produce: first-week post rate and peer-connection rate). The “Failure signal” column describes the observable indicator that the pattern is failing; the “Fix” column is the intervention that addresses the root cause, not a symptom workaround.

Pattern	What it looks like	Why it underperforms	Failure signal	Fix
Too many events	Operator schedules a welcome webinar on Day 2, a community tour or Q&A on Day 4, and a coffee chat or office hours on Day 6. New members receive calendar invitations or Slack announcements for all three in their first week. Some operators also add a Day 1 “getting started” video or a pre-recorded community orientation session.	New members in week one do not yet have enough context about the community to evaluate whether a specific event is worth their time. Each event invitation requires an implicit cost-benefit evaluation (“Is this webinar for members at my level? Will the other attendees be working on similar things? Is this the right moment to commit 60 minutes to this community?”) that the new member cannot complete without a prior social model of the community. Members who lack the context to answer these questions default to deferral, which looks like low event attendance but is actually a scheduling decision failure, not a content failure. Additionally, multiple event invitations in a single week compete with the Day 3 nudge for notification attention and suppress its response rate.	Event attendance below 15% of new members (relative to new-member cohort size, not total community size). Low Day 3 nudge response rate (below 20%) in weeks with multiple event invitations. Member feedback citing “overwhelming” or “not sure where to start.”	Remove all mandatory or scheduled events from week one. Move optional live events to week two or three, timed after at least one async activation action (introduction post or weekly thread reply) has occurred. If an event already exists in week one (e.g., a weekly community call that new members are invited to), make the invitation explicitly optional and send it as a single channel post rather than a direct DM to new members. Reduce the week-one notification load to the three-slot minimum: Day 0 DM, Day 3 conditional nudge (non-posters only), and the weekly thread prompt. Measure first-week post rate and Day 3 nudge response rate in the four weeks after removing events from week one. If both metrics improve, the event timing was the cause.
Mandatory participation	New members must complete an onboarding quiz or survey before accessing full channel access. Or: new members are required to attend a welcome session as a condition of community access. Or: the Day 0 DM requires the member to complete three separate steps before they receive a response (introduce yourself, fill out the member profile form, join three goal-track channels) — presented as a required checklist rather than an optional sequence.	Mandatory steps add cognitive load to a moment (first day in the community) that already carries significant cognitive demand: new workspace navigation, new social norms inference, initial self-presentation. Each mandatory step is a potential exit point where a member decides that the activation cost exceeds the activation benefit they currently perceive. New members have not yet had an experience in the community that calibrates their benefit perception — they are evaluating based on their pre-join expectation, which is typically lower than the actual value. A mandatory quiz or form introduces a cost at the exact moment when the benefit-to-cost ratio is at its lowest point in the member’s lifecycle.	High day-one introduction-post rate but low day-seven first-week post rate (members complete the mandatory step to get access but do not return). Day 0 DM response rate below 30% (members who see mandatory steps in the DM do not reply at all). Member feedback citing “too much to do upfront” or “wasn’t sure what was required vs. optional.”	Replace all mandatory steps with optional ones. The introduction prompt in the Day 0 DM should be framed as an invitation (“When you have 5 minutes, introduce yourself here”) not a requirement (“Before you can access the community, complete the following”). If channel access gating is a non-negotiable product decision (e.g., the operator wants to confirm goal-track before unlocking goal-track channels), move the gate after the first post rather than before it — requiring an introduction to unlock channels is a lower-friction gate than requiring a form or quiz, because the introduction post is the action the operator wants anyway. Remove all multi-step checklists from the Day 0 DM. One action only: post an introduction.
Full-member engagement dependency	Each new member is assigned a “buddy” from the existing membership who is responsible for welcoming them and replying to their introduction. Or: long-tenured members are asked in a channel announcement to reply to all new introductions this week. Or: a “peer welcome team” of 5–10 volunteers is designated to reply to new-member posts, with the expectation that the team covers all new joins.	This pattern creates a dependency between the new member’s activation and the availability of a specific existing member. When the buddy is unavailable (on vacation, busy with their own work, or simply forgets), the new member receives no response — exactly the zero-peer-connection outcome the programme was designed to prevent, but now with additional disappointment because the operator explicitly promised a personal welcome. The buddy programme also scales poorly: as the community grows, the pool of available buddies does not grow proportionally unless the operator actively recruits and rotates. The safer design is programming (the weekly thread prompt) that generates peer connections as an emergent byproduct of a format that existing members are already motivated to participate in for their own reasons, not because they were assigned a new member to welcome.	Peer-connection rate variance above 20 percentage points week over week (high in weeks when buddies are active, low in weeks when they are not). Buddy volunteer dropout within 60 days (most buddy systems start with enthusiastic volunteers who reduce participation after 4–6 weeks). New-member introductions receiving zero replies in weeks when the buddy pool is unavailable.	Replace the buddy system or new-member reply obligation with a standing peer-welcome rotation: 5 established members who each commit to replying to one new-member introduction per week, with a rotating schedule rather than a permanent assignment. The rotation model distributes the obligation without creating a single-point-of-failure dependency. Additionally, add a weekly thread prompt (slot 3 of the minimum viable calendar) that naturally puts new members in a thread alongside established members — reducing the proportion of new-member activation that depends on introduction replies specifically.
Week-two formats in week one	Operator launches a monthly goal-setting thread in week one. Or: new members are invited to join a three-month accountability group on day two. Or: a structured project with a multi-week timeline is presented as the primary week-one engagement opportunity. Or: the week-one programming includes a “what are you building?” showcase format that requires a polished description of the member’s work product.	Month-two and month-three programming formats require the new member to make a long-term commitment (goal for the month, accountability partner, multi-week project) before they have confirmed that the community is worth committing to. The commitment cost is highest at the moment when community value is least demonstrated. Members who make a week-one commitment and then churn at month one have both ended their subscription and created a negative outcome for their accountability partner or project group. The failure mode compounds: the more elaborate the week-one commitment format, the more damage a week-one churn produces to the members who were assigned to work with the churning member.	Week-one commitment completion rate below 30% (most members who start a monthly goal thread in week one do not complete it). Accountability group formation with week-one joiners that breaks down in weeks 3–4. New members citing feeling “behind” or “not ready” for the community’s structured programmes in their first week.	Move all commitment formats (monthly goal threads, accountability groups, multi-week projects) to month two or month three. The trigger for inviting a member to a commitment format should be their completion of the three-slot week-one minimum viable calendar (intro post + goal-selection + goal-track channel participation), not their join date. A member who has posted at least twice and received at least one peer reply is ready for a commitment format; a member who has not yet posted is not. Add the invitation to the commitment format in the Day 7 scorecard message for members who have completed the activation sequence — at that point, they have a demonstrated relationship with the community and the commitment format deepens an existing engagement rather than front-loading one.

The common thread across all four wrong patterns: each one adds complexity or commitment before the new member has a sufficient experiential foundation (at least one post and one peer reply) to evaluate whether the complexity or commitment is worth accepting. Week-one programming failures are almost never caused by too little programming — they are caused by programming that is too demanding, too coordinated, or too forward-committed for a member who has not yet had a single peer interaction in the community.

Two-metric measurement reference

Two metrics determine whether week-one programming is working. These are not the five metrics in the paid community metrics dashboard reference card (which covers the full measurement framework for community health); they are the two week-one-specific leading indicators that are measurable within 7 days of each new cohort’s join date. Both metrics should be reviewed weekly for the cohort whose 7-day window closed in the past 7 days. The table below defines each metric, specifies the healthy benchmark, at-risk threshold, and structural-problem threshold, describes the intervention for each band, and explains how to measure it from data available in Slack without additional tooling.

Metric	Definition	Healthy benchmark	At-risk threshold	Intervention	Measurement method
First-week post rate	The percentage of new members (whose join date was 7–14 days ago, so they have completed their first 7-day window) who published at least one original post — defined as a thread-starter, not a reply to another member’s post — in any public channel during their first 7 days. Introduction posts in the #introductions channel count. The metric measures whether the programming created a moment for the new member to take a public action. A member who replied to another member’s thread (a reply, not a thread-starter) but never started their own thread is counted as not-posted for this metric, because the goal is to measure whether the programming produced the “first original contribution” behaviour that correlates with month-three renewal.	45–60% — with Day 0 DM, Day 3 conditional nudge, and weekly thread prompt all running consistently. Members who post in week one renew at month 3 at 3–4× the rate of members who never post. The 45–60% range is achievable in communities where the Day 0 DM introduction prompt is specific (the three-element format: name, work, one goal) and the Day 3 nudge copy is goal-specific rather than generic.	40–45% — Day 3 nudge is sending but the nudged action is not producing posts. Most likely cause: the specific post the nudge recommends is in a channel where new member posts receive no replies within 24 hours. A new member’s first post that receives no response produces a worse activation outcome than not posting. Check: does the nudge link to a channel where recent new-member posts have received replies? Below 40% — structural problem: the community lacks a visible low-social-risk post type for new members.	40–45%: identify which channel the Day 3 nudge recommended for a first post. Count the last 10 posts by new members in that channel. How many received a reply within 24 hours from a non-operator member? If fewer than 6 out of 10 received replies, the channel is not suitable as the nudge destination. Switch the nudge destination to the channel with the highest new-member reply rate. Additionally, notify 3 established members to actively reply to new-member posts in that channel for the next two weeks. Below 40%: add a pinned weekly prompt thread to the primary content channel as a designated landing zone. Include a specific mention of the current week’s prompt in the Day 3 nudge copy for new members who have not yet posted. The prompt thread lowers the social cost of a first post by providing a structured question that any member can answer.	From Slack member activity export: download the member export (Slack → Settings & administration → Manage members → Export). Filter for members whose “Joined” date was 7–14 days ago. For each member, check whether they appear as the thread-starter in any channel post in their first 7 days. The Slack member export shows “Messages posted” count but does not distinguish thread-starters from replies — for precise measurement, search each channel for posts from each new member by username in the 7-day window, or use a Slack app that logs thread-starters separately. For manual calculation in small communities (below 30 new members per week), scanning the #introductions channel for introduction posts is sufficient for an approximation — introduction posts correlate with first-week post rate at 80–90% for communities using the Day 0 DM introduction prompt.
Peer-connection rate	The percentage of new members (whose join date was 7–14 days ago) whose introduction post in the #introductions channel (or the first original post they made in any channel) received at least one reply from another community member who is not the operator or a designated community manager account, within 24 hours of the post being published. Peer-connection rate measures whether week-one programming is producing community engagement — peer-to-peer replies — rather than only operator-to-member exchanges. An operator who replies to every introduction within an hour may have a 100% reply rate on introductions but a 0% peer-connection rate, which is the wrong outcome: operator replies are better than silence but do not produce the peer-to-peer dynamic that predicts month-three renewal.	40–60% — for communities running a weekly async thread prompt that draws established-member participation. The 40–60% range means that 4–6 in 10 new members who post an introduction receive at least one non-operator reply within 24 hours. The weekly thread prompt is the primary driver of this metric because it creates a weekly occasion where established members are already participating, making it more likely that they will also notice and reply to new-member introductions posted around the same time.	25–40% — established members are not organically replying to new-member introductions. Most likely cause: the introductions channel has high volume and established members have muted or deprioritised it. Below 25% — structural problem: new members are posting introductions into a channel where replies are rare, which produces the zero-peer-connection failure pattern. Below 25%, the lurker-from-day-one pattern (member opens Slack daily but never posts again after the unresponded introduction) becomes the dominant new-member archetype.	25–40%: establish a standing peer-welcome rotation with 5 established members who each commit to replying to one new-member introduction per week. This is a rotation (each member does it once per week regardless of new-join volume) rather than a buddy assignment (each new member is assigned to a specific buddy). The rotation prevents single-point-of-failure when one buddy is unavailable. Notify the rotation members via a weekly DM that lists that week’s new-member introductions. Below 25%: the #introductions channel is likely not being read by established members. Cross-post a summary of new-member introductions to the main content channel at the end of each week (“Welcome this week’s new members: [names and one-line summaries from their intros] — say hi in the thread”). This cross-post surfaces the introductions to established members who have not been reading #introductions and creates the peer-reply opportunity outside the introductions channel.	Manual check only (no Slack export includes reply metadata at the thread level). Procedure: at the end of each week, open the #introductions channel and scroll to the introductions posted by members who joined 7–14 days ago. For each introduction, count whether it has at least one reply from a non-operator member. If the reply came more than 24 hours after the introduction was posted, it does not count toward the 24-hour peer-connection rate (though it still represents a peer interaction that is better than none). Record the count as a fraction (e.g., “7 out of 12 introductions received a peer reply within 24 hours = 58%”) and track the rolling 4-week average to distinguish trend from weekly noise. Note: for communities with fewer than 5 new members per week, the metric will be noisy week-to-week (a single unanswered introduction can move the rate by 20 percentage points). Use a 4-week rolling average rather than a single week’s reading for decision-making.

Metric sequence. Check first-week post rate before peer-connection rate each week. If first-week post rate is below 40%, the root cause is almost always in the Day 0 DM or Day 3 nudge — the programming is not creating the moment for action that would produce a post. Fix the DM sequence first. If first-week post rate is healthy (45%+) but peer-connection rate is below 35%, the root cause is that posts are going unanswered by established members — the Day 3 nudge and weekly prompt are working to produce posts, but the community’s established-member reply behaviour is not generating the peer connection. In this case, the peer-welcome rotation intervention is appropriate. Treating both metrics as the same problem produces the wrong intervention at each threshold.

Novelty window reference

The novelty window is the period immediately following join during which the community occupies a structurally elevated position in the new member’s attention hierarchy. Programming delivered during the novelty window converts to first posts at 2–3× the rate of identical programming delivered after the window closes. The table below shows how member attention level, the right programming type, and the most common operator mistake change across the four phases of the 0–7 day window and after day 7. This is a qualitative reference — the attention level column describes the relative attention state, not a measured scale. Its value is as a reminder that programming timing within week one is not neutral: day 0 is not the same opportunity as day 5, and day 5 is not the same as day 10.

Days from join	Member attention level	Right programming type	Most common operator mistake
Day 0–3	Highest. The member just paid and the payment has made the community temporarily salient. They will open Slack without a notification, explore channels unprompted, and read member lists. They are forming the first version of their mental model of what this community is and who is in it. This is the highest-leverage programming window in the entire member lifecycle and is typically the most under-programmed in communities that treat onboarding as passive.	Onboarding automation only. Day 0 DM fires on join and delivers the structured introduction prompt + goal-selection question. The Day 0–3 window is not the right time for events, group formats, or commitment asks — the member has not yet completed the first action (posting an introduction) that establishes their presence in the community. All other programming should wait until the introduction post has happened.	Sending too many messages or invitations in the first 48 hours. The operator who sends the Day 0 DM, a “getting started” resource list, an event invitation, and a community values document in the first 48 hours produces a notification overload that suppresses the Day 3 nudge’s response rate. Day 0–3 is a one-message window: the Day 0 DM only.
Day 3–5	Still elevated. Members who have already posted an introduction are in the community with a foothold — they have been seen, and if they received a peer reply, they have formed a reason to return. Members who have not yet posted are in a window of mild friction: they have been in the community for 3 days without taking action, and the mental cost of the “late introduction” is beginning to accumulate. Both states are still within the novelty window’s elevated attention period, but the member who has not yet posted is at higher risk of the permanent-lurker pattern after day 5.	Day 3 conditional nudge (for non-posters) + exposure to the weekly thread prompt if it runs in this window. The Day 3 nudge is the primary intervention for recovering non-posters before the novelty window closes. The weekly thread prompt, if it runs on Monday and the member joined on Wednesday, will be encountered on day 5–6 — within the novelty window and at a moment when the thread already has established-member replies to observe and join.	Sending the Day 3 nudge with generic copy (“Just a reminder to introduce yourself”) rather than goal-specific copy (“I see you’re interested in [goal track] — there are members working on exactly that”). Generic Day 3 nudge copy produces 30–50% lower response rates than goal-specific copy because it does not demonstrate that the operator has read the member’s Day 0 goal-selection response — the personalisation signal is what converts the nudge from a reminder into a demonstration of community attention.
Day 5–7	Closing. The novelty window is closing. Members who have not yet posted by day 5 are forming the behavioural pattern of non-participation that typically persists for the rest of their membership. The member who opens Slack on day 5 and scrolls without posting is reinforcing a read-only behaviour. The weekly thread prompt, if encountered in this window, is the last high-probability opportunity for a first post — the structured format and visible established-member replies reduce the social cost of participation at the moment when the member is most likely to scroll without posting.	Weekly async thread prompt (primary). If the weekly prompt does not fall in this window (e.g., it runs on Mondays and the member joined on Tuesday, so the next prompt is day 6), the Day 7 scorecard message — a brief summary of what the member has done and a specific next step — is the last automated touch in the week-one sequence. The Day 7 scorecard should include a direct link to the most recent weekly thread prompt if it is still open (within 48 hours of posting).	Interpreting lack of posting by day 5 as disinterest and reducing programming in response. Operators who send fewer messages after day 3 to “avoid overwhelming” members who have not responded are removing the programming at the exact moment when it is most needed to recover non-posters before the novelty window closes. The Day 7 scorecard is the final recovery touchpoint in the week-one sequence; removing it eliminates the last automated opportunity for a nudge during the novelty window.
Day 7+	Competed. The novelty window has closed. The community now competes for attention on equal terms with every other Slack workspace, newsletter, and tool in the member’s daily workflow. Members who have not posted by day 7 are almost always in a stable non-participation pattern that week-one programming cannot change after the fact. The weekly thread prompt continues to give them opportunities to participate, and occasional direct DMs referencing their specific goal track can produce posts from non-posters — but the per-contact conversion rate drops sharply compared to the day 0–7 window.	Structured async formats (weekly thread prompt, monthly goal-setting thread, member spotlight format) running on the standard community schedule. Optional live touchpoints (week 2+ events) are appropriate now for members who completed async activation in week one. Do not introduce new week-one programming formats for members who have passed day 7 without posting — the intervention for post-novelty-window non-posters is a personal DM referencing their goal-track, not a new programming format, because the problem is no longer a programming gap but a relationship gap.	Attempting to recover day-7+ non-posters with event invitations or programme announcements. The operator who notices that 40% of last week’s new members have not yet posted and responds by inviting them to a welcome webinar is applying a type 3 programming intervention to a problem that requires a personal DM. Post-novelty-window non-posters respond to personal outreach (a DM that references their goal track and asks a specific question) at 3–4× the rate of event invitations. For members who are past day 7 without a post, the weekly DM that the operator or a peer-welcome rotation member sends is more effective than any community-wide programming announcement.