A ninety-day plan that takes a community from open question to pilot decision

A ninety-day plan can turn an open question into a pilot decision when an organisation tests one member task and records the limits of its evidence. The scenario follows a team considering peer support, from its first checks to a choice to stop, revise, repeat or continue. A small cohort is not proof of lasting demand.

The ninety days at a glance

The schedule below allocates the ninety days to six periods, with two decision gates. It is a planning template, so adjust the pilot length, but fix it before recruitment begins.

Research takes 30 days, design and preparation take 30, and the pilot and its decision take 30.

Start with one defined member task

The organisation starts with one decision: could a community help eligible members with a defined task through peer exchange?

The evidence is incomplete, so the team identifies what falls outside scope instead of assuming a space should be built. If testing is justified, it will be a bounded pilot, not a claim of proven demand.

The accountable owner is named before the work is divided. The subject matter indicates whether privacy, security, legal, accessibility or safeguarding reviewers are needed; each reviewer is assigned a decision and a point in the process. That makes their input specific rather than an open-ended request for comments.

The first check is whether the proposed task is already served another way. The team names the current alternative, then reviews relevant support cases, event questions and member interviews. That comparison helps distinguish a member need from an assumption that a community is the answer.

Reconstruct the evidence trail

Before designing a service, the team checks who might take part, what they have done so far, and whether peer exchange could help. It recruits through more than one route, including people outside the organisation's preferred channel, and records why someone might decline or stay silent.

The team uses member interviews to ask about recent behaviour and possible reasons not to join. The Home Office design system’s user research guidance recommends recruiting actual or likely users. Because that guidance is for UK public services, a commercial team still needs to define its own sample and limitations; a small qualitative group is not representative of England.

The first decision is whether the available evidence supports stopping, further research or designing a pilot. In this scenario, a better knowledge article or a direct service change remains a valid outcome. The team does not continue simply because it has already spent time researching the possibility.

Read the findings at their true scale

The finding is deliberately limited: the checks can identify a task worth testing, reasons people might not participate, and gaps in recruitment. They cannot establish durable demand or show that a small qualitative sample represents people across England. The team records those limits alongside the evidence.

If the preferred channel has supplied most of the responses, the team treats that as a gap to investigate rather than proof that other people have no need. It can examine hidden eligibility rules and seek further evidence before deciding whether to proceed. What was not reached matters to the decision.

Design only what the evidence supports

With a narrow task and a reason to test it, the team maps one repeatable activity from entry to closure. It assigns welcoming, facilitation, expert answers, moderation and incident escalation, writes participation rules, and defines access, retention, export and departure arrangements.

The accountable owner also confirms who reviews privacy, security, legal, accessibility or safeguarding issues, and when each decision is due. The responsibilities can be checked against community team roles. The aim is a workable operating route for this test, not a full service model built ahead of evidence.

Only after those operating needs are clear does the team select technology. It uses a trial dataset to check permissions and export, and can use the National Cyber Security Centre's cloud security guidance to inform supplier questions. The organisation still needs a risk assessment suited to its information and configuration.

Operate the test as an observation

The team invites a defined cohort, explains the experimental period and sets expectations about staff availability. Operators practise ordinary decisions and serious cases before opening. The scenario tests include an unanswered request, harmful contribution, data request and administrator absence, using tabletop exercises.

Before recruitment, the team records a baseline using the same definition planned for later measurement. It decides how feedback, corrections and incidents will be reviewed, sets a stop condition and names who can invoke it. These choices make it possible to notice operational problems without changing the test measures casually.

A small review group checks the invitation and joining information before they go to participants. The team asks them to spot hidden eligibility rules, unexplained visibility and promises operators cannot meet. During the test, it observes whether eligible needs receive an appropriate response, how much effort is required, and where work leaves the community route.

Match the final choice to the evidence

At the end, the owner compares the findings with the intended member outcome, baseline, operating capacity and safeguards. The review includes staff time, specialist input and implementation, rather than treating the licence as the only cost. It also notes which groups were absent and what remains unknown.

Participants who contributed, watched silently or disengaged can each offer relevant feedback. The team reviews safety and workload, and avoids changing rules or measures midway without recording the change and separating evidence gathered before and after it. The decision reflects what happened in this test, not what the team hoped would happen.

The owner chooses to stop, repeat, revise or continue. Expansion requires another capacity and risk check because success with a small cohort does not establish how a public or much larger service will behave. The team archives research, decisions and source dates under its agreed retention policy.

Rules worth carrying forward

The scenario leaves a short set of rules for the next decision: keep the claim within the evidence, assign decision rights, and make it possible to stop. These principles apply whether the evidence leads to a pilot, more research, a different service response or no community at all.