/
/
/
Team & Cohort Management

Team & Cohort Management

Structures that maintain themselves.

Build teams and cohorts by hand, or define them by rule so they stay current on their own as members join, move, and leave.

The group fulfillment chain

Sell

Somebody buys for a group

>

Enroll

The group gets in

>

Delegate

Somebody else runs it

>

Report

The buyer sees results

Static groups go stale within a quarter

A team you build by hand is accurate on the day you build it and slightly wrong every day after. People join, change roles, finish a program, or leave. On a platform of any size the maintenance quietly stops happening, and six months later your cohort structure describes a membership that no longer exists. Dynamic teams solve this by defining membership as a rule instead of a list.

Available now as custom build.

TEAMS is currently implemented as custom solutions for trusted partners, and everything on this page works today through that process. A fully self-managed plugin is in active development as part of the Gamplify Suite.

How teams get built

Everything available to you.

Most platforms end up running both kinds side by side.

Built by hand

Static teams

Built by rule

Dynamic teams

How they nest

Structure

Who does what

Team roles

Where they work

Team spaces

Worked example

A cohort that rebuilds itself every month

Nobody maintains a list. The list maintains itself.

Dynamic cohort

Rule-based

Sell

Rule: anyone tagged Cohort 12 and active

Defined once, in about a minute.

Enroll

Nine new members purchase and are tagged

They appear in the cohort, on the leaderboard, and in the team space immediately.

Delegate

Two members lapse and lose the active tag

They drop out of the cohort without anybody noticing they needed to.

Delegate

One is promoted to captain by the coach

From the front end. No admin login involved.

Report

Team reporting always reflects who is actually there

Which is the entire point, and the thing static lists cannot promise.

Recipes

Three you could build this afternoon.

Read them as when, only if, then. That is the whole grammar of the system.

Define by rule wherever you can

When

A team is being created

Only if

Membership follows a knowable attribute

Then

Build it dynamically. Hand-maintained lists are accurate for about two weeks

Rotate challenge teams

When

A challenge ends

Only if

A new one begins

Then

Rebuild teams from a fresh rule, which stops cliques hardening and gives everyone a new shot at the top

Let a member belong to more than one

When

A member joins a challenge

Only if

They are already on a regional team

Then

Allow both. Regional and challenge teams measure different things and should score separately

Before you build

Three things worth knowing.

Note

Dynamic teams depend entirely on tag hygiene. If your tagging is sloppy, your cohorts will be too.

Note

Test what happens when somebody stops qualifying. Silent removal from a team they were proud of is a bad experience.

Note

Decide early whether team membership is visible to members. Some structures are useful internally and unhelpful publicly.

The rest of TEAMS

Team & Cohort Management is one of 7 parts.

Team & Cohort Management

You are here

Credit, Seat & Token System

Gamplify TEAMS

Bulk Enroll

Gamplify TEAMS

Admin Management

Gamplify TEAMS

Multiple Admin Levels

Gamplify TEAMS

Course & Content Access Control

Gamplify TEAMS

Team Reporting

Gamplify TEAMS

Put Team & Cohort Management to work.

Tell us what you are trying to get members to do, and we will show you the Flow that does it.

Scroll to Top