Partner AMA Planning Checklist for Web3 Teams
An AMA is easier to prepare when the brief names a question instead of a reach target. Start with what the audience should understand after the conversation, who can answer accurately and what the listener can do next.
This checklist is for a Web3 team planning a joint session with a relevant project. It is an operating template, not a promise of attendance, leads or a series of increasingly large guests. If you have not chosen the partner, start with the partner selection worksheet.
Write the brief before asking for a date
| Field | What to write |
|---|---|
| Audience question | A specific problem both audiences recognise. |
| Reason for this pairing | What each speaker can explain from their own work. |
| Available evidence | Official documentation, a working demonstration or an approved statement. |
| Next action | One useful destination for the listener; state any access restrictions. |
| Roles | Host, speakers, moderator, technical backup and person owning written follow-up. |
| Unresolved matters | Topics that require another owner, are confidential or are not ready to announce. |
Read the brief from the partner's side. If it only explains what your project wants, revise it. The guest should be able to contribute something more useful than an endorsement.
Confirm the format and the public links
X Spaces is a live audio format with host and speaker controls. Check the controls available to the host account before announcing the event. If you plan to record or reuse audio, agree that with speakers and tell listeners; verify the actual recording setting before starting.
- Open the event link on a phone and on desktop.
- Confirm the timezone in the invitation and the public announcement.
- Check speaker names, affiliations and permission to use partner branding.
- Give the moderator official product links and a route for questions they cannot answer.
- Rehearse entry, sound, speaker handover and the backup plan.
- Agree who can approve changes to the announcement.
A technical fallback can be as simple as publishing a written Q&A if the live conversation cannot happen. Do not announce a recording or resource as available until its link works.
Give the host a short run sheet
- Opening: name the question, introduce the speakers accurately and explain where official links are posted.
- Context: ask each speaker to explain the problem from their own product or community.
- Demonstration: walk through a concrete use case and its limitations. An unfinished feature must be described as unfinished.
- Audience questions: group related questions; do not guess an answer when the responsible person is absent.
- Close: repeat the agreed next action and explain where unanswered questions will be addressed.
Keep a private note of unanswered questions and assign an owner. An audience question is not permission to add the person to a mailing list or send unsolicited sales messages.
Publish the answer that the event made possible
After the session, check names, quotations and links against the recording or speakers' confirmation. Publish a concise recap that resolves the central question, links to the resource and identifies anything still open. Share only recordings and clips you are authorised to use.
For reporting, separate live audience, later plays, visits to the destination and actual enquiries. Retain the platform's metric names and time windows. Do not add them together and describe the sum as unique listeners or buyers. The measurement worksheet provides a place to record what is observed and what remains unknown.
Check readiness without inventing a score
The session is ready when both teams approve the topic, the host can operate the format, the official links work and somebody owns the follow-up. If the product answer is missing, resolve it or narrow the topic before promoting the event.
To discuss help with a partner AMA as part of pre-marketing, see Social Proof & Partnership. The schedule, responsibilities and scope need to be agreed for the specific project.