// INSIGHTS
Session Feedback People Will Actually Complete
6 min read
Session feedback fails on timing, not on question design. An email at 9pm on day two gets a response rate in the low single digits. The same three questions on the phone, thirty seconds after the applause, get a completely different number. The engineering work is making the ask land inside that window, keeping it short enough to finish standing up, and producing results someone can use to write a report on Monday.
The ninety-second window
When people leave a hall, their phone is already in their hand. They are checking the time, checking the next session, checking WhatsApp. That is the window. A push notification at two minutes after the scheduled end, deep-linked straight into a three-question form with no login screen in between, catches people while the session is still in their head. Ten hours later they have sat through four more talks and can no longer distinguish them.
The trigger matters as much as the timing. If you are already scanning delegates out of halls, use that scan-out event to fire the survey, so only people who actually attended get asked. Falling back to the scheduled end time works, but it asks everybody about a session most of them did not attend, and those responses are noise dressed up as data. Ask only about sessions the delegate has a scan record for, and the response quality goes up before you have changed a single question.
Keep the form to one rating, one multiple choice and one optional free-text box. Every additional question costs completions, and the fourth question costs more than the third. Free text should accept Hindi, regional languages and romanised input without complaint, because that is what people will type on a phone keyboard while walking. If your analysis pipeline cannot read those responses, that is a pipeline problem to solve, not a reason to force everyone into English.
What length costs you
What the feedback module has to do
Session-triggered surveys
Each session carries its own survey, fired by scan-out or by the scheduled end time. Nobody is asked to rate a talk they did not attend.
Multilingual question sets
Question text and free-text input in English plus Hindi or the relevant regional language, and Arabic for UAE events. Delegates answer more honestly in the language they think in.
Anonymous by design
Responses are stored without the delegate identifier, and completion is tracked in a separate table holding only a flag. That separation is what makes the anonymity claim true rather than a promise.
A live dashboard for the committee
Ratings by session, by track and by speaker, updating through the day. Programme chairs can move a room or extend a Q&A on day two based on what day one told them.
Instrumenting feedback across a two-day agenda
Attach a survey to every session
Do this during content load, not on the morning of the event. Sixty sessions means sixty survey objects, and doing it by hand at 6am produces mistakes.
Trigger on the exit scan
Fire the notification about two minutes after the delegate scans out or after the scheduled end. Earlier interrupts the closing remarks, later loses the window.
Escalate once, then stop
One reminder at the end of the day for outstanding sessions, and nothing after that. A third ask trains delegates to mute the app entirely.
Close the loop in public
Show top-rated sessions on the app home screen on day two. Delegates who see their input reflected are measurably more likely to respond again.
Where feedback programmes fail
The most common mistake is one generic end-of-event survey with twenty-two questions covering venue, food, content, registration and Wi-Fi. It gets a poor response rate, it gets those responses from the least representative slice of the audience, and the free text is dominated by whoever had the worst lunch. Split it: three questions per session in the moment, and a short event-level survey the following morning while people are travelling home.
The second failure is an anonymity claim that the data model contradicts. Under the DPDP Act, telling delegates their feedback is anonymous and then storing a joinable delegate identifier against every response is a genuine problem, not a technicality. If you need to know who completed feedback, in order to release an attendance certificate for instance, store a completion flag in a separate table and keep the response content unlinked. The third failure is simpler and more common: nobody is assigned to read the results. Name the owner before the event and agree what decision the data is going to inform, or you have built a very efficient way of collecting numbers that nobody opens.
Common questions
Star ratings or free text?
Both, with the free text optional. Ratings give the programme committee something comparable across sixty sessions, and free text explains why a rating happened. Expect a minority of delegates to write anything, and treat those comments as qualitative signal rather than as a representative sample.
Should we gate attendance certificates on feedback?
It works and it has a cost. Completion rates rise sharply, and a portion of those extra responses are people tapping the middle option to get through the form. If you do gate it, use the responses for directional comparison between sessions and be sceptical about small differences.
Do multilingual surveys actually get used?
Yes, particularly for free-text answers at events outside the metros. Delegates who are comfortable reading English questions will still write their honest comment in Hindi or their regional language when given the option. The work is on your side, in making sure the analysis pipeline handles mixed-script text rather than discarding it.
Feedback that arrives while people still remember
Send us your session list and we will map the trigger and question design against it.
