Session board: plan a participant-led analytics meetup

A session board lets participants see which analytics discussions are proposed, who will host them and where they fit. Use the card, grid and fifteen-minute exercise below to build a first version and identify unconfirmed details before sharing a programme.

Content checked: 19 October 2026.

When does a session board help?

A session board is a visible map of proposed discussions, their hosts, their times and their locations. It helps a small analytics meetup let participants shape the programme without making everyone sit through the same presentation. Your first deliverable is a readable working board, not a polished conference agenda.

Start with a bounded purpose. A group of independent retailers might want to leave with one question to investigate in its sales reporting. This is a fictional planning example, not a reported client engagement. Participants can propose discussions around that purpose, while the organiser makes space and timing constraints explicit.

Do not use an open programme for information everyone must receive together. A mandatory briefing, an urgent operational decision or a single shared instruction may need a common session instead. Separate that fixed requirement from optional discussions. Freedom to choose a room is useful only when choosing is genuinely allowed.

Write a short invitation before opening the board: who the meetup is for, what kind of question belongs there and what participants should bring. Say that proposing a discussion does not require a finished slide deck. A question and a willing host can start a discussion.

What does the MeasureCamp example establish?

My verified experience relevant to this subject is helping organise MeasureCamp Baku. APA TV’s report dated 17 October 2022 identifies me, Anar Rustamli, and Kamal Allazov among the professionals who organised the event together. That is evidence of co-organising, not evidence that I designed or operated a particular board.

The official MeasureCamp Baku website separately displays a 5 November 2023 event date. It describes a programme created on the day, with attendees adding their names and topics to a session board. These are different dated references. The later website must not be treated as a record of my specific responsibilities at the earlier event.

The worksheet below is a new suggested planning example for readers. It is not an archived MeasureCamp document, an official organiser manual or a claim about measured results from my work. Keep that distinction when adapting it: an event format can inform a recommendation without proving that every suggested field was historically used.

Turn a topic into one usable proposal

Ask for a question before asking for a title. “Reporting” is a category. “Why do our order records and our analytics purchases disagree?” gives people something they can discuss. A narrow question makes it easier to decide whether two proposals belong together or need separate time slots.

Open a new Notepad document from Windows Start, or TextEdit > File > New on Mac, using Format > Make Plain Text if needed. Add these card fields: title; one question; host; input to bring; small output; availability; information not to share. Add the grid and conflict note below. A host starts and guides the discussion, not necessarily a lecture; confirm their agreement.

Make the output modest and inspectable. It could be a list of explanations to test, a diagram of one reporting step or an agreed question for a later investigation. Avoid promising that a short discussion will repair an entire measurement system. For business questions about metrics, use the small-business KPI guide as preparation, rather than turning every proposal into a general metrics lecture.

Use anonymised or fictional teaching inputs when live customer information is unnecessary. A participant should be able to describe the shape of a problem without publishing a customer list. Check permission before attaching a screenshot. The finished proposal should tell an attendee what they can contribute and what they might take away.

• Name one question.
• Confirm the host accepts the role.
• Specify an output and an information boundary.

Build the time-and-room grid

Put time slots down the left and real available rooms across the top. Do not create a second track until you know that a second usable space exists. Noise, access, seating and equipment can make an apparently empty room unsuitable. A remote breakout also needs a host and a clear joining route.

The example table uses invented topics and times. Replace them with your own constraints; they are not recommended event durations or a historical programme. Include the session host and the question on each occupied cell. Mark unresolved details as awaiting confirmation rather than quietly treating them as agreed.

Keep a little room for movement in your timetable. The time a discussion ends and the time the next one starts need not be identical. Choose the actual spacing for your venue, then communicate it consistently. Someone reading the board should know whether an empty cell is available, reserved or deliberately unused.

If participants are joining across regions, check the displayed time and zone before sharing the programme. The meeting time-zone check addresses a separate scheduling risk. A correct room grid cannot fix an ambiguous local time in an invitation.

How should you resolve competing requests?

First check for impossible assignments: the same host in two rooms at once, a session placed outside the host’s availability or a room without required equipment. These are constraints, not popularity questions. Resolve them before asking which discussion people prefer. Otherwise a vote may select something you cannot actually run.

Next offer a simple place to note pairs of topics people would like to attend. Collect topic pairs rather than unnecessary personal contact information. Treat these notes as signals, not a reliable headcount or an attendance forecast. Explain that limited space may prevent every preference from being satisfied.

Move a proposal when a feasible alternative exists and its host agrees. Merge proposals only when their questions and intended outputs genuinely overlap. A discussion about choosing a metric differs from investigating missing events. Similar vocabulary does not make them interchangeable. Preserve both if combining them would hide one participant’s actual problem.

Give one person responsibility for the current board. When a slot changes, mark the old location with the new time and place, and tell the host. Date any image shared in a group chat. A photograph taken before a change should not compete silently with the live board as an equally current programme.

Make a first version in fifteen minutes

Use this as a short preparation exercise, not a promise to organise a whole meetup in fifteen minutes. At the end you should have a visible first version and a list of unconfirmed details. Do not advertise tentative sessions as confirmed merely because they fit neatly into a table.

Minutes one to three: write the meeting purpose and available spaces. Minutes four to seven: complete two proposal cards using questions you already have. Minutes eight to eleven: place the cards into slots and check host availability. Minutes twelve to fifteen: record a possible topic conflict, choose the board owner and write how changes will be announced.

If a host has not replied, keep the card tentative. If no real question has been proposed, your result is an empty structure ready for contributions, not a participant-designed programme. This shows what is missing before invitations.

For a discussion that becomes a practical learning exercise, a training activity worksheet can define the exercise separately. Do not overload the board with instructions, test inputs and assessment criteria. The board helps people choose a discussion; a practice brief helps them carry out a task inside it.

Save the note in Documents as session-board-draft.txt using Windows File > Save As or Mac File > Save; add a date if the name exists. Close and reopen it to check the card, grid and unconfirmed fields. In plain text, keep each time slot on its own line with room entries separated by |. Keep the draft easy to revise.

Close with a useful record, not an inflated claim

At the end of each discussion, record the question explored, the example considered, one unresolved point and an optional next action. Keep an opinion separate from an agreed decision. Do not assign an absent person work, or list a volunteer as responsible before they have accepted the task.

Copy this closing note: question; input examined; tentative explanation; next check; consenting owner; proposed check date. It is a short continuity record, not a full transcript. A session can be valuable without reaching agreement, especially when its useful result is identifying which evidence is missing.

If you later automate summaries, review the meeting-notes workflow before sending recordings or personal information to a tool. The board itself does not require a recording. You can preserve a useful next step with a short manually checked note and the participants’ permission to share it.

Learning a new tool after a meetup is another separate job. The team AI training guide can help structure that follow-up, but do not label a discussion as completed training. Likewise, a proposed session is not evidence that it actually happened. Mark the final board accordingly.

Afterwards, record intended investigations and distinguish held sessions from proposals. Preserve changes and cancellations with the final board. Revenue, capability and learning outcomes require separate evidence.