Running a 12-week team challenge: the operations checklist

A 12-week challenge is not difficult because the work is heavy; it is difficult because there are many small milestones that are easy to forget. The checklist below follows the order in which they actually come up, split by phase.

The numbers in this article are illustrative examples, not data from a real event.

Before opening day (T-3 weeks to T-1 day)

T-3 weeks

• Settle the competition structure (see the article on choosing a structure).
• Settle the conversion factors and the points cap; give them to somebody outside the organising group to read and recalculate by hand.
• Appoint a coordinator. Above 50 participants, appoint two: one for the numbers, one for communication.

T-2 weeks

• Open registration. Collect exactly four fields: participant code, name (stored separately), team, expected activity type.
• Send the data commitment statement (see the minimum disclosure statement in the article on activity data).
• Set the results schedule: the same hour every week. Do not leave it flexible — a fixed time creates a rhythm.

T-1 week

• Build a sample scorecard with dummy data for week 1 and send it to every team in advance.
• Test the submission link on a real phone, not only on a computer.
• Draft the template emails: submission reminder, receipt confirmation, results announcement, complaint handling.

T-1 day

• Finalise the team list. Print the code list for the coordinator.
• Check once more: does everyone know the submission deadline?

Weeks 1–2: settling the rhythm

The main job is not scoring but reducing the number of repeated questions. Every question received in week 1 should go into a public FAQ that same day.

• Monday: remind people about last week’s submission.
• Tuesday: close the data, calculate the scores.
• Wednesday: publish the scores plus one short line about something interesting from the week.
• Thursday to Sunday: take complaints about the previous week.

Do not change the factors during this phase. If you find an error in the formula, log it and fix it from week 3, with a clear announcement.

Weeks 3–8: the phase where people drop out

This is where the participation curve starts to fall. Three things hold the rhythm:

• Reset points at each stage. With a 2-week stage structure, this is when the race is cleared and people come back.
• Publish by team, not by individual. Individual leaderboards create pressure and drive the weaker participants away.
• Recognise returning participants. One sentence — “team X had 3 people submit again after 2 weeks away” — does more than a prize.

Week 6 is a milestone worth checking: as a rule of thumb (ours, not research-based), if submissions have fallen below half of week 1, look at the structure before blaming the participants.

Weeks 9–11: preparing to close

• Announce the final results date from week 9, not week 11.
• Settle how late complaints are handled: accepted only within 7 days of the final announcement.
• Prepare the summary: number of participants, total activity minutes, and the share who submitted all 12 weeks. These are three useful figures, unlike “total kilometres”, which is easily inflated and not comparable.

Week 12 and after

Week 12

• Publish the final scores, together with the scoring conditions used.
• State the complaint deadline publicly: 7 days.

7 days later

• Lock the scorecard. No further edits.

90 days later

• Delete detailed personal data. Keep the aggregate version (number of people, total minutes, completion rate) for next year’s reporting.
• Delete the code-to-name table. This step is easy to forget.

Three common operational mistakes

1. Publishing scores late. Participants lose trust faster when scores are wrong than when they are late — but both reduce participation (our view).
2. Answering complaints one-to-one only. Every answer should go into the public FAQ, even when the person who asked receives a private reply as well.
3. Never setting a data end date. Data deletion is easy to forget unless the date is scheduled from the start.

Sources

No external sources: this is an operating proposal from the editorial team.