NeuGroup Platform Launch
Master plan — Gradual community platform · Target launch June 1, 2026
Vision
One login. Every event, session, person, and piece of content relevant to you — visible in one place. Members browse everything happening across the network, see what they can join now vs. what requires access, connect with peers working on the same problems, and receive curated communications based on their actual interests.
For NeuGroup: rich member data, centralized onboarding, and a micro-apps layer that makes the platform feel personal and dynamic — not generic.
Member experience
- Browse ALL events — see what's joinable vs. gated
- Async topic threads (Slack-feel) + live sessions in one place
- Self-serve connection — ask a question, get matched to a peer
- Curated newsletter based on interests + peer problem set
- "X others are working on the same problem as you"
- Mobile app + desktop, single login
NeuGroup operations
- Centralized onboarding — not APGL-dependent
- Checks & balances system flagging incomplete setups
- Rich data on engagement, interests, peer overlap
- Gated content as a conversion tool for non-members
- Intercom helpbot already integrated
- Micro-apps layer for personalized dynamic experiences
Content at launch
1,200+
Articles at community level
4
New articles/month (ramping)
~50
Cross-network sessions/year
4
Group types
Platform architecture — what lives where
Gradual native modules
Events
Groups
Forums
Boards
Content library
Member directory
Member profiles
Spaces
Notifications
Points & activity
Surveys
Jobs
Messaging
Analytics
Mobile app
Email digest
SSO
API
Community level
Visible to all members
- 1,200+ article content library
- All events (browsable — access varies)
- Cross-network topical sessions
- Member directory
- Job board
- Promoted group content (teaser / dangle access)
- Intercom helpbot
Group level
Gated by group + space rules
- Tier-specific resources & content
- Peer group events & sessions
- Regional pod content
- Execution sprint cohort workspaces
- Group-only discussion forums
- Promoted to community = visible but access-gated
Micro-app layer
Built on top, authenticated
- Survey snapshot landing pages
- Interactive member connection library
- AI "ask & connect" bot (planned)
- Hosted on Cloudflare (this domain)
- Auth integration with Gradual: TBD
Key Gradual constraint: Everything at community level is one-size-fits-all — no personalized content visibility. Personalization happens via newsletters (external tool), spaces (access gating), and the micro-apps layer.
Group taxonomy — four types, one member can belong to multiple
Membership tiers
- Mega cap treasurers
- Large cap treasurers
- Asst. treasurers
- + other tiers
Regional pods
- Northeast
- West coast
- Midwest / South
- + other regions
Execution sprints
- Time-limited cohorts
- Sprint cohort A, B…
- Archivable after sprint ends
Cross-network topics
- FX & hedging
- Cash & liquidity
- + more topics
- Module: TBD
A single member can belong to all four types simultaneously — e.g. mega cap treasurer + northeast pod + FX sprint cohort + cash & liquidity topic.
Permission model — three stacked layers
all-members space
Most important space to get right
- Cross-network events, directory, job board
- 1,200+ article library
- Topical session browse page
- Set on every active paid member at onboarding
guest-[event-id] space
Non-member event registrants
- Auto-assigned on event registration
- Sees that event only — nothing else
- No access to member content, directory, or forums
- Conversion opportunity: upsell post-event
Onboarding & user management
New centralized process
- APGLs still add membership in Salesforce — unchanged
- Salesforce sync triggers Gradual contact creation
- 1–2 technical ops people own all Gradual setup
- They assign: groups, spaces, tier, pod, survey trigger
- Welcome email sent only after full setup confirmed
- APGLs get confirmation when member is fully live
Checks & balances
- Airtable / Notion tracker — every new member + setup status
- Checklist per member: profile ✓ groups ✓ spaces ✓ survey ✓
- Auto-flag: any member missing criteria after 48 hrs
- Weekly audit — ops owner reviews incomplete setups
- Goal: zero members with broken permissions at launch
Why centralize: APGLs are not technical. The Gradual permission model (contact role + group + space) is complex enough that one misconfiguration breaks a member's entire experience. Centralize for v1, loosen after the system is proven.
Surveys — four persistent instruments
Onboarding survey
Fires once on first login. Captures interests, priorities, and peer problems. Feeds newsletter curation and "X others working on the same problem." Stored on member record permanently.
Trigger: first login · One-time · Required
Quarterly experience survey
Sent to all members every quarter. NPS + open feedback on platform and sessions. Completers get access to benchmark results page via space assignment.
Trigger: quarterly · All members · Results gated to completers
Pulse surveys
Ad hoc, targeted by tier or topic group. Reuse same space mechanism as experience survey — assign space when open, revoke after. No new infrastructure per pulse.
Trigger: ad hoc · Targeted segment
Post-event surveys
Auto-triggered after each session via Gradual notification or email. Results feed member record and micro-app survey snapshots. No separate space rule required.
Trigger: post-event · Per-event · Results go to member record
Cross-network topical sessions
Structure
- ~50 live virtual sessions per year
- Each topic = persistent async thread (Slack-channel feel)
- Example topics: FX & hedging, cash & liquidity, capital markets
- Sessions promoted to community event page — anyone can browse
- Access to join gated by topic space / group membership
- Members self-select into topics they care about
Open decision — urgent
Groups vs. forums module
- Groups: structured, joined, gated — like a channel you join
- Forums: open threads, browse without joining — closer to Slack
- Forums may better match the "browse all topics at once" vision
- Decision gates all space design for topical sessions
- Action: test both in Gradual this week
Micro-apps layer — hosted at connectmap.bromsey.work
Live
Intercom helpbot
Already integrated with Gradual. Handles member support. Underutilized — needs configuration and knowledge base build-out.
In progress
Survey snapshot
Interactive HTML landing page showing survey results. Hosted on Cloudflare. Auth integration with Gradual TBD.
In progress
Member connection library
Browsable, filterable library of members. Filter by tier, interest, problem area. Drives peer connection.
Planned
Ask & connect bot
Member asks a question → returns a card: "You should connect with [Name]." Powered by onboarding survey data.
Planned
Curated newsletter engine
Personalized digest based on survey interests. Shows sessions, content, and peer overlap data. Requires external email tool.
Planned
Future micro-apps
Spin up targeted landing pages with Claude — benchmark snapshots, event recaps, connection prompts. All hosted here.
Auth open question: Micro-apps need to know who the logged-in member is to personalize content. Does Gradual expose an SSO token or API that Cloudflare-hosted pages can consume? This is the key technical unlock for the entire personalization vision.
Launch timeline — 10 weeks to June 1
Now → April 11
Decisions & foundation
- Groups vs. forums for topical sessions
- Finalize space taxonomy
- Lock centralized ops ownership
- Build onboarding checklist / tracker
- Design onboarding survey fields
- Confirm Salesforce → Gradual sync behavior
- Gradual auth / SSO capability check
April 14 → May 16
Build & configure
- Set up all groups + spaces in Gradual
- Configure event permissions
- Build onboarding + experience surveys
- Draft member how-to guide
- Recruit 5–10 beta testers
- Run user validation sessions
- Draft comms plan + pre-launch emails
- Job board: decide + build
- Survey snapshot micro-app live
May 19 → June 1
Launch prep
- Triage beta feedback
- Train ops owners on Gradual SOP
- Send pre-launch member comms
- Soft launch to one pilot tier group
- Full launch June 1
- 30-day post-launch check-in ready
Data architecture — member record & system of record
Member creation flow
Where do members get created?
- PGMS is likely the system of record — source of truth for membership
- Member created in PGMS → API push to Gradual → contact created
- Gradual member data syncs back to PGMS custom object as read-only
- No manual creation in Gradual directly — always flows from PGMS
- Open: does Gradual have a real-time webhook or is it batch sync?
- Open: what fields are pushed — email, name, tier, group assignment?
Activity points — reconciliation needed
30 existing flows → Gradual native points
- Currently tracking activity across Cvent, community, and other sources
- Gradual has its own native points / engagement scoring system
- Need to: map existing 30 flows to Gradual point triggers
- Need to: backdate all historical scores into Gradual on launch
- Need to: deprecate or redirect old flows that now overlap
- Open: does Gradual accept a points import via API for backdating?
- Open: who owns the flow reconciliation — ops or a contractor?
Priority: The PGMS → Gradual API connection needs to be confirmed and tested before any onboarding SOP is finalized. If this sync is unreliable or manual, the entire centralized onboarding model breaks.
Events — creation, ownership, migration
Event creation process
Who does it and how?
- Needs a single owner — likely the centralized ops person(s)
- APGLs request events; ops person builds them in Gradual
- Header image: needs a defined owner — ops, marketing, or a template system
- Recommend: 3–4 Canva templates for event headers so anyone can produce them consistently
- Open: how many new events per month across all groups?
- Open: does Gradual have a bulk event creation tool or is it one-by-one?
Event discoverability
How members find their events
- Create events inside the group module for group-specific events
- Promote to community level → shows in global event listing for all members
- Members see: "I can join this" vs. "this requires access" in one calendar view
- Global calendar doubles as a public-facing page showing all NeuGroup activity
- Cross-network topical sessions live at community level — no group required to browse
- Open: can the global calendar be embedded on neugroup.com?
Migration — must hire out
1,300 events to migrate
- This is not a one-person job. Budget for a contractor or VA to execute this.
- Need to define: which events migrate (all? past 2 years? active only?)
- Need to define: what data migrates per event — title, date, description, attendees, recording?
- Need to define: do migrated events get group assignments or land at community level?
- Gradual may have a CSV/API import path — confirm before scoping contractor cost
- Estimate: 2–4 weeks of focused contractor work depending on import tooling
Recommended event structure: Group event (created inside group) → promote to community → appears in global calendar. Members in the group see it in their group feed AND the global calendar. Members outside the group see it in the global calendar but hit an access gate when they try to register. Clean, simple, consistent across all group types.
Implementation help — what you actually need right now
Hire: Gradual implementation partner
- Someone who has launched on Gradual before
- Owns: group setup, space config, event templates, permission testing
- Frees you to direct strategy, not execute config
- Find via: Gradual's own partner network, community Slack, Contra
- Timeline: hire this week or next
Hire: event migration contractor
- 1,300 events will not migrate themselves
- Scope: define what migrates, map fields, execute import
- Can be a technical VA or data ops freelancer
- Find via: Upwork, Toptal, or ask Gradual directly
- Timeline: scope in April, execute April–May
You: strategy & decision-making only
- You answer: what should the experience feel like?
- You answer: what's v1 vs. v1.1?
- You answer: who owns what process?
- Everything else gets delegated or contracted out
- This is the right use of your time at 12 weeks out
Boards — the module we haven't fully mapped yet
What boards are
Structured async content feed
- More organized than a forum thread, less formal than an event
- Good for: announcements, resource drops, pinned updates, Q&A
- Can live inside a group (gated) or at community level (all members)
- May be the right home for cross-network topical async discussion
- Could replace or supplement forums depending on Gradual's implementation
Potential use cases for NeuGroup
Where boards might fit
- Inside tier groups: APGL announcement board per group
- Cross-network topics: one board per topic (FX, cash, etc.) for async thread + session links
- Community level: NeuGroup announcements, new content drops, job board posts
- Sprint cohorts: deliverable board where participants post outputs
- Open: does Gradual boards support threaded replies or is it flat?
Key decision
Boards vs. forums vs. groups for async discussion
- Forums: open-ended threaded discussion, browse without joining
- Boards: structured feed, better for curated content + announcements
- Groups: container for all of the above, gated by membership
- These three modules overlap significantly — need to define one primary use per module to avoid confusion
- Recommended: groups = container · boards = structured content · forums = open discussion. Test this in Gradual before locking.
Don't let all three modules solve the same problem. If members can post async in forums AND boards AND group feeds, they won't know where to go. Pick one primary async layer per context and stick to it.
Topic tags — governance & taxonomy
The problem if you ignore this
- "FX" + "fx-hedging" + "Foreign Exchange" + "hedging" = same thing, 4 tags
- Search becomes useless, content gets buried, members get frustrated
- Happens fast — within weeks of launch if no one owns it
- Retroactive cleanup is painful and time-consuming
- Free-form tagging by multiple people is the root cause — fix this at the start
The fix
Pre-defined taxonomy, single owner
- One person owns tags — same ops person who owns user creation
- Tags are pre-defined in Gradual, not free-form entry
- New tags require approval before creation — no self-serve tagging
- Quarterly audit: merge dupes, retire unused tags
- Tag list lives in the onboarding SOP so new ops staff know the rules
Starter tag taxonomy — to be refined
FX & hedging
cash & liquidity
capital markets
risk management
peer group
execution sprint
regional pod
technology
talent & careers
macro & markets
member spotlight
resource
announcement
+ add more →
Marketing plan — onboarding drip & member communications
Three distinct audiences, three distinct sequences. New members, lapsed members, and non-member event guests each need a different message and CTA. Don't send the same email to all three.
Sequence 1 — New member onboarding drip
Sequence 2 — Lapsed member reactivation
Sequence 3 — Non-member event guest conversion
Ongoing recurring comms
- Weekly digest: upcoming events + new content — all members
- Curated newsletter: personalized by survey data (v1.1 — needs external tool)
- Session reminder: 24hr before any registered event
- Post-session: recording link + survey + related content
- Quarterly: experience survey + benchmark results for completers
Pre-launch comms — June 1 sequence
- T-4 weeks: teaser — something big is coming
- T-2 weeks: platform preview — here's what it looks like
- T-1 week: how-to guide — download the app, here's your login
- T-1 day: we go live tomorrow
- Day 0: we're live — log in now
- Day 7: first week check-in — any questions?
Tool needed: All drip sequences require an external email tool (HubSpot, Mailchimp, ActiveCampaign, or similar) with behavioral triggers — Gradual's native email is likely blast-only, not trigger-based. Confirm what's already in your stack before building new sequences.
Open questions — parking lot
Urgent — blocking other decisions
Groups vs. forums for cross-network topical sessions
Which module gives the Slack-channel browse experience? Groups = join to access. Forums = browse without joining. Decision gates space design for all ~50 annual sessions. Test both in Gradual this week.
PGMS → Gradual API: how does member creation actually work?
Is the API connection real-time webhook or batch? What fields get pushed (email, name, tier, group)? Does Gradual accept a write-back to PGMS custom object as read-only? This is the foundation of the entire onboarding model.
Activity points: does Gradual accept a historical import?
You have 30 existing activity tracking flows across Cvent, community, and other tools. Gradual has its own points system. Need to know: can historical scores be backdated via API? Which of the 30 flows overlap with Gradual native triggers and can be retired?
Event migration: what does Gradual's import tooling look like?
1,300 events need to migrate. Before scoping contractor cost, confirm whether Gradual has a CSV or API import path. Also need to define scope: all events, or past 2 years only? What data fields migrate?
Important — answer before May
Salesforce → Gradual sync: how automated is it?
Does the integration auto-create a Gradual contact when a membership is added in Salesforce, or does someone manually trigger it? Determines how much of onboarding can be zero-touch.
Micro-app authentication
How do Cloudflare-hosted micro-apps verify a member's identity against Gradual? Does Gradual expose an SSO token or API? Without this, personalization across all micro-apps is impossible.
Can the global event calendar be embedded on neugroup.com?
The vision is for the global calendar to serve as a public-facing page showing all NeuGroup activity. Does Gradual support embedding or a public calendar URL that can be iframed into the marketing site?
Who creates events and who owns header images?
Needs a single accountable owner. Recommend: centralized ops creates events, Canva templates for headers so quality is consistent. How many new events per month across all group types? Does Gradual support bulk event creation?
Space assignment: manual vs. automated
Can Gradual trigger a space assignment automatically (e.g. survey completed → space granted) or is every assignment a manual action? If manual, staffing requirement for ops is significantly higher.
Newsletter curation mechanism
Gradual sends one community-wide newsletter. Personalized newsletters based on survey data require an external email tool. Is this in scope for June 1 or v1.1?
Job board: native Gradual module or external?
Does Gradual have a native job board module? If not, simplest embed or workaround that doesn't require a separate login? Three posting types needed: open roles, member available, team member recommendation.
Boards: threaded replies or flat feed?
Boards could be the right async layer for cross-network topics and group announcements — but only if Gradual supports threaded replies. If it's flat, forums may be better for discussion. Test this specifically when exploring the groups vs. forums question.
Module clarity: boards vs. forums vs. group feed — one job each
All three modules can host async content. Without a clear rule for which module does what, members won't know where to post and content gets scattered. Decision needed before configuring any group: boards = structured/curated, forums = open discussion, group feed = announcements only (or some other clear split).
Does Gradual support pre-defined tag taxonomies (no free-form)?
Tag governance only works if members can't create new tags themselves. If Gradual allows free-form tagging, you need an admin lock or a manual cleanup process. Confirm this in Gradual settings before launch.
What email tool is already in the stack for drip sequences?
Onboarding drip, lapsed member reactivation, and guest conversion sequences all require behavioral trigger-based email — not blast email. Gradual's native email is likely blast-only. What's already in use at NeuGroup — HubSpot, Mailchimp, ActiveCampaign? This determines how much needs to be built vs. configured.
v1 vs. v1.1 scope decision
Micro-apps beyond survey snapshot, curated newsletters, and ask-and-connect bot are high-value but high-effort. Need an explicit cut list so the launch checklist doesn't creep.