How to run a call for conference speaker proposals

To run a call for conference speaker proposals, decide what your paying audience needs to learn, publish clear submission rules, and give reviewers a shared way to judge each proposal. Then build a programme from the strongest relevant sessions, confirm speakers on the terms you advertised, and tell everyone what happened to their submission.

So you're organising a conference, you need speakers, and everyone on your team seems to know someone who would be great on stage. An open call helps you reach beyond those connections. But putting a form online doesn't automatically give you a useful programme. You still need to tell people what you're looking for and make decisions you can explain.

The first thing you want to do is separate the call from the conference announcement. One attracts people who want to contribute. The other helps people decide whether to buy a ticket. They should describe the same event, but they have different jobs. A speaker needs submission instructions. A buyer needs a reason to attend.

This guide walks you through the complete process, including a call template, submission questions, a review rubric, and a fictional conference example. The aim is a programme your audience would pay to experience, with a selection process your team can actually run.

Start with the audience's problem

Before you ask anyone to propose a talk, write down who will be in the room and what they're trying to do. "Business professionals interested in innovation" won't help a reviewer choose between proposals. "Operations managers trying to reduce production delays without replacing their entire system" gives them something to work with.

Think about the decisions attendees need to make after the event. What are they struggling to understand? Where do they need practical guidance? Which assumptions deserve a challenge? Use your previous attendee questions, sales conversations, and feedback to build this picture. If you need a better way to collect that feedback, start with these post-event survey questions.

Then write a programme promise in plain English. For example, "You'll leave with a practical way to identify delays, test a fix, and explain the cost to your finance team." That's a fictional promise, but notice how much work it does. A speaker knows what to teach. A reviewer knows what to look for. Your marketing team knows what it must substantiate.

This doesn't mean every session has to be a how-to tutorial. A debate can help an attendee reconsider a decision. A research presentation can explain something they couldn't see before. A case study can show where an apparently sensible plan went wrong. Each format still needs a clear reason to exist in your programme.

Decide what the open call can fill

You don't have to put every speaking slot through the same process. Your conference may combine invited sessions, open submissions, and clearly labelled sponsored content. Decide which slots the call covers before it opens. Otherwise, reviewers can spend days assessing proposals for space that your sales team has already promised elsewhere.

Count the available sessions against your real timetable. Include questions, room changes, breaks, and any equipment setup. If you haven't planned the wider event yet, work through how to organise a paid conference first. A promise of twenty talks means very little if you only have room for twelve.

Choose the accepted formats and explain their purpose. A short talk might introduce a narrow idea. A longer workshop might require attendees to complete an exercise. A panel needs a question worth discussing and a plan for moderation. Don't call something a workshop just because it lasts longer than a presentation.

Set your policy on multiple proposals and multiple speakers too. Can someone submit several ideas? Can a team propose a shared session? If you only want one accepted session per person, say so. These are your programme choices, rather than rules every conference has to copy.

Keep sponsor promises visible to the programme owner. You can sell a speaking opportunity, but buyers should understand what they're attending. Editorial selection and commercial inclusion need their own descriptions and approval routes. Hiding that distinction creates a problem for speakers, reviewers, and delegates.

Publish the terms before people apply

A speaker shouldn't have to finish a proposal to discover that you can't cover travel, expect them to buy a ticket, or require a recording agreement they can't accept. Put the practical terms beside the call. People need to decide whether participation works for them before they invest the time.

State whether you pay a speaking fee, provide admission, reimburse approved expenses, or offer financial assistance. Explain which costs you cover, any limits, and who approves them. If support isn't guaranteed, make that clear. Your event budget needs to include the support you have promised, including the costs of workshops and additional speakers.

For a real example of separating submission from assistance, PyCon US's 2026 talk guidance describes speaker travel grants and asks applicants to indicate whether they need one. Its guidance also asks speakers to identify the audience, explain what attendees will learn, and provide an outline with timing. You can borrow those questions without copying its funding policy.

Explain the event location, delivery format, language, and availability requirements. If speakers must attend in person, say so. If remote delivery is possible, explain who makes that decision. Don't imply that an invitation letter guarantees permission to travel.

Describe your plans for slides, photography, recordings, and promotional extracts. Tell applicants which arrangements are required and where they can read the proposed agreement. Have the agreement reviewed for your event before relying on it. Don't invent broad rights language because it looks official. A short call can link to detailed terms while still explaining what the speaker is being asked to accept.

Set dates you can keep

Work backwards from the date you need a confirmed programme. Your call needs time for submissions, assessment, programme decisions, speaker replies, and replacements. The public announcement comes after the necessary confirmations. Leaving review until your marketing team needs names tomorrow puts everyone under pressure to take shortcuts.

Here is a fictional timetable for a conference taking place in November. The call opens in May and closes in June. Review happens in July. Decisions go out in August, with a stated reply deadline. Your team then confirms replacements, prepares session descriptions, and publishes the programme. These dates illustrate the sequence, rather than a universal planning standard.

Give the deadline a date, time, and named time zone. "Midnight on Friday" is surprisingly easy to misunderstand. Also explain whether people can edit after submitting and which version reviewers will assess. If you accept drafts before the deadline, make the final submission action obvious.

Put the decision date in the call. Applicants may need to arrange leave, travel, or other speaking commitments. If your team falls behind, tell them before the promised date passes and give a revised date you can support.

Decide how you'll handle extensions before someone asks. If you extend the public deadline, announce it wherever you promoted the original call. If a documented access problem needs an individual remedy, record what happened. Quietly accepting late proposals from friends makes your published deadline look optional.

Write a call people can use

Your call page should answer the questions an interested speaker will ask in the order they'll ask them. Who is this for? What contribution do you want? What does participation involve? How do they apply? When will they hear back? They shouldn't need to piece those answers together across social posts.

Use the following fictional example as a starting point. Replace its audience, dates, formats, and support terms with arrangements you have actually approved. Keep the useful detail even if your marketing team wants a punchier opening.

We're inviting proposals for Practical Operations Conference, an in-person event for managers responsible for production and service delivery. Our audience wants methods they can test at work, supported by real experience and an honest explanation of the limits. We welcome experienced presenters and people proposing their first conference session.

We're accepting talks about diagnosing delays, improving handovers, and testing operational changes. Each proposed session should explain who it helps, what attendees will learn, and how you'll use the available time. We aren't accepting standalone product demonstrations through this call. Sponsored sessions follow a separate route and will be identified in the programme.

Talks last thirty minutes, including questions. You may submit two proposals, but we will accept no more than one session per speaker. Accepted speakers receive conference admission. Travel assistance is limited and requires a separate decision. Please tell us if assistance would be necessary for you to participate.

Submit through the form by 17:00 London time on 30 June. You can edit until that deadline. We will email decisions by 14 August, and selected speakers must confirm by 21 August. The call page includes our speaker terms, recording arrangements, review criteria, and contact details for submission support.

Ask for enough information to judge the session

Keep the proposal form short enough to finish and detailed enough to review. Every field should answer a decision your team needs to make. Asking for a complete slide deck at this stage is often unnecessary work. Asking only for a catchy title leaves reviewers guessing about the substance.

Separate the public description from the private information reviewers need. The public abstract should help a delegate choose a session. The outline can explain the argument, examples, activities, and timing in more detail. Private notes can flag material that shouldn't appear on the event website.

A practical submission form can ask for:

• Session title and a short description suitable for the public programme.

• Intended audience, experience level, and any knowledge attendees need beforehand.

• What attendees should understand or be able to do afterwards.

• Session format, preferred duration, and a timed outline.

• The experience, evidence, or work the speaker will use to support the session.

• Speaker contact details and a separate biography.

• Commercial interests, relevant affiliations, or sponsorship connections.

• Delivery requirements and whether support is needed to participate.

• Confirmation that the applicant has read the submission rules and speaker terms.

PyCon AU's proposal guidelines show why this detail matters. They distinguish the public abstract from optional private reviewer notes, encourage enough detail to understand the session, and suggest a timing breakdown. Their examples also connect the subject to a particular audience. The lesson is to ask what the session will do, rather than reward an impressive job title.

Put word limits beside the fields, with an example of the detail you expect. Avoid collecting the same answer several times under different labels. A biography helps later promotion, but it shouldn't become a substitute for the proposal itself. You'll use both eventually, for different reasons.

Make submitting accessible and predictable

Test the actual form, including its confirmation email. Fill it in on a phone. Use the keyboard to move through it. Check what happens when an answer exceeds the limit or a required field is missing. A beautiful call page doesn't help if the submission disappears at the final step.

W3C's guidance on form instructions recommends explaining required and optional inputs and expected formats. It also explains that placeholder text is not a replacement for labels. Use those principles when choosing or configuring your form. Applicants should still understand a field after they've started typing into it.

Offer a way to prepare answers before opening the form. You can publish the questions on the call page so people can draft elsewhere. If the form supports saving and returning, explain how. If it doesn't, say that before someone begins a long response.

Give each submission a reference and send the applicant a copy or summary. Confirm that you received it, state the next date, and explain how to make a correction. A receipt means received, not accepted. Keep that distinction clear in the wording.

Provide a contact for people who encounter an access problem or need another submission arrangement. Route those requests to someone who can act. Don't ask applicants to describe sensitive personal circumstances in a field every reviewer can see. Collect only what your team needs, explain who receives it, and keep operational support information separate from session scoring.

Promote the call beyond familiar names

Publish the call where relevant contributors already spend time. Your previous speakers and attendees are a useful starting point, but they're only part of the audience. Ask professional groups, industry communities, universities, and practitioner networks to share it when the subject genuinely fits their members.

Give partners a short description, a deadline, and the call page link. Explain the contribution you want rather than sending a vague request for "thought leaders". Someone with useful experience may not describe themselves as a speaker at all. Tell them what they could bring to the room.

If you welcome first-time speakers, make that invitation practical. Offer a proposal clinic, a sample outline, or clear answers to common questions. Explain what help accepted speakers can expect. Don't promise mentoring unless someone on your team has time to provide it.

Keep proposal support separate from selection. A clinic can explain how to describe a session without promising acceptance or privately rewriting a friend's application. Publish useful answers for everyone when they address a common question. That saves your team from repeating replies and prevents guidance from becoming an advantage available only through personal contacts.

Watch which subjects and communities your submissions cover while the call is open. A missing topic may need more specific outreach. You can invite people to apply without guaranteeing them a slot. If you commission a session outside the call, record it as an invited contribution and protect the space already offered through open submission.

Give reviewers a rubric before they start

A rubric is simply the shared set of criteria your reviewers use. It makes the discussion more useful than "I liked this one". Keep it tied to your audience and programme promise. You aren't grading the speaker's ability to write a polished application for its own sake.

For a practical commercial conference, you could assess audience relevance, useful learning, supporting evidence, and deliverability. Audience relevance asks whether the session addresses a real problem for the people you expect to attend. Useful learning asks what changes for them afterwards. Evidence asks whether the proposed material supports its claims. Deliverability asks whether the session fits its format and time.

Use plain descriptions for your scoring levels. "Weak" could mean the proposal doesn't show how it serves the stated audience. "Adequate" could mean it identifies a relevant problem but leaves a key part unclear. "Strong" could mean it gives a convincing session plan, supported examples, and a clear attendee benefit. Adjust these descriptions for each criterion.

Then write comments that explain the score. "Needs more detail" isn't particularly useful. "The outline names a method but doesn't explain the example attendees will work through" tells the programme chair what is missing. Reviewers should be able to distinguish a fixable gap from a session that doesn't fit the event.

Score a few sample proposals together before dividing the real submissions. Discuss disagreements and refine unclear instructions. Don't change the rubric midway because a familiar person's proposal scores badly. If a genuine problem forces a change, reassess the affected submissions using the same revised criteria.

Handle conflicts and confidentiality properly

Ask reviewers to declare relationships that could affect their judgement. These may include their employer, a current client, close collaborators, friends, family, or a financial interest in the speaker's acceptance. A reviewer shouldn't be deciding whether their own proposal gets a slot. Name someone who can handle these cases independently.

ACM SIGPLAN's conference review policy requires conflicted reviewers to decline and keeps submissions within the authorised review process. It also says a conflicted programme chair must not participate in that submission's review or decision. This is a research-conference policy, rather than a rule governing your commercial event, but the separation is a useful model.

Assign each proposal to reviewers with relevant knowledge and enough time to read it. Independent first assessments help reveal real disagreement. Don't let the first confident voice in the room determine everyone else's score. When reviewers disagree, look at their reasons and expertise before treating the average as the answer.

Consider hiding names and biographies during the first assessment. If you do, explain which fields should avoid identifying information and what happens later. You can't promise perfect anonymity when a distinctive case study may identify its author. You can still reduce the temptation to judge a proposal by reputation alone.

Keep the review workspace limited to authorised people. Tell reviewers how to handle proposals, notes, and outside tools. Don't upload private submissions into an unapproved service for convenience. Give applicants a clear explanation of how their information supports review and who receives the details needed for event delivery.

Select a programme, not a score leaderboard

Scores help you find strong proposals. They don't automatically produce a good conference. Your audience needs a programme with useful differences between sessions, sensible progression, and enough choice. Accepting the highest scores without reading them together can leave you with several versions of the same talk.

Group the shortlist by topic, audience level, format, and practical outcome. Look for duplication and gaps. Does every session assume advanced knowledge? Does each speaker use the same example? Have you selected lots of opinions but nothing that helps attendees apply the ideas? Go back to your original programme promise.

Suppose two proposals teach the same method. One is better suited to beginners, while the other explains difficult exceptions for experienced managers. You might keep both if your audience needs both and the descriptions make the difference obvious. If they repeat the same material, choose the stronger fit and record why the other wasn't selected.

Discuss the range of perspectives represented too. Look at the experiences, organisations, industries, and operating conditions behind the sessions. If you only hear from large firms with large budgets, a smaller operator may struggle to apply the advice. Programme balance needs substance, rather than a collection of biographies that look different on a website.

Record the final reason for each decision separately from the review score. "Strong proposal, but duplicates an accepted session" is different from "doesn't explain its attendee benefit". That distinction matters when someone withdraws. It also stops your rejection email from pretending every unsuccessful proposal was weak.

Set a common approach to clarification requests. Decide who sends them, what applicants can change, and how long they have to reply. You might allow someone to explain an unclear exercise without replacing the entire proposal after the deadline. Keep the original submission and the clarification together so reviewers understand what changed. If you offer this opportunity to one borderline proposal, check whether others have the same kind of gap. The chair should record why clarification was requested and how the reply affected the decision. That makes the process easier to repeat when a reviewer asks why another applicant received a chance to explain.

Work through a fictional selection decision

Imagine Practical Operations Conference receives several proposals about reducing handover delays. Your team has space for two sessions on this subject. This example is invented to show the process, and none of its outcomes is a claim about a real conference.

Proposal A describes a repeatable method, a worked example, and a realistic outline for beginners. Proposal B has a polished abstract and a well-known speaker, but the outline mainly describes their company's product. Proposal C examines where a similar method failed, with examples suitable for experienced managers. Proposal D has a useful idea but doesn't explain how a proposed group exercise would fit.

Your reviewers assess the content first. A has a clear audience benefit. B raises a concern about the promised educational purpose. C could add a useful perspective, provided its claims and examples hold up. D needs clarification on deliverability. The chair asks D a narrow question through the same clarification process available to other applicants.

After that reply, D still needs more time than the advertised format allows. The team selects A and C because they serve different attendee needs. It declines B under the published policy on product demonstrations. It offers D a place on the relevant waitlist only if a suitable longer session could realistically become available.

Notice what didn't decide the programme. Nobody needed to argue that A was more famous than C. The team didn't invent a new policy to exclude B. And it didn't promise D a slot it couldn't provide. The written audience, format, and review criteria did the difficult work before the final meeting.

Send decisions that mean something

Write separate messages for acceptance, waitlist, and rejection. Check names, session titles, and status before sending. One wrong merge field can undo weeks of careful review. Have someone read a sample of every message type and test the reply address.

An acceptance should describe the offered session, duration, delivery format, support, and next steps. Ask for confirmation by a stated deadline. If you've changed the proposal's format or length, make it an offer the speaker can accept or discuss. Don't silently announce a workshop as a short talk.

A waitlist message should say what being waitlisted means. Explain which session type the person could fill, how long the offer remains open, and whether you need a reply. Never ask someone to book travel against a possibility. You can ask whether they're still interested and identify the point at which you will release them.

A rejection can be direct and kind. Thank the person, confirm the decision, and explain whether feedback is available. If you give a reason, make sure it matches the record. "The programme is full" doesn't explain a proposal that failed a stated submission rule. A short accurate response beats a cheerful paragraph that says nothing.

Tell every applicant, including people you already know. Keep the decisions private until accepted speakers have agreed and you are ready to announce. Submitting a proposal isn't permission to advertise someone as part of your programme.

Confirm the session before marketing it

Once a speaker accepts, turn the proposal into a delivery plan. Confirm the final title, public description, biography, pronunciation, support arrangements, and contact person. Check that the published description still reflects the session you selected. A stronger marketing headline shouldn't change what attendees will actually learn.

Ask about equipment and access requirements early enough to resolve them. Assign a deadline for slides or other material if your event needs one. Explain how speakers request changes and who approves them. The Linux Foundation's seL4 Summit speaker guide gives a useful operational example, with separate instructions for schedule issues, audiovisual requests, slides, and speaker contacts.

Bring those tasks into your wider event planning checklist. Someone needs to own each confirmation, rather than assume the programme team has passed everything to production. A named owner should check that every promised arrangement reaches the speaker. A workshop's equipment request can affect room choice. A speaker's availability can affect the timetable. Fix those dependencies before printing the programme.

Keep a replacement plan for each session category. If someone withdraws, check whether a waitlisted proposal serves the same audience and fits the available format. Ask the replacement to confirm current availability. If you need to make a visible programme change, update the event information and tell ticket holders through your established communication process.

Review the call after the conference

After the event, compare the selected session promise with what attendees experienced. Ask useful questions about relevance, level, clarity, and application. "Was the speaker good?" mixes too many things together. You want to learn whether your selection criteria predicted a session worth attending.

Review the submission process with speakers and reviewers too. Which form questions helped? Which caused confusion? Did your decision date hold? Were support arrangements clear? Where did your team spend time resolving issues it could have prevented in the call? Record specific changes for the next edition while people remember them.

Keep your final selection record and the operational notes you need under your organisation's retention rules. Remove access people no longer need. Then revise the next call using the evidence, rather than reopening every preference from scratch.

A useful call for conference speaker proposals starts with the audience, makes participation clear, and gives your team a consistent way to judge the ideas. Publish those rules, use them when decisions get uncomfortable, and confirm the programme before promoting it. That's how an open call becomes something your paying attendees can trust.