Everyone's raving about Fellow's meeting templates and note-taking, but I see teams cargo-culting formats without any data on whether they actually work. The software gives you the hammer, so every meeting looks like a nail. The "best way" to get feedback isn't just another feature inside the app—it's a process, and you have to design it to avoid the usual self-serving noise.
First, stop relying solely on the built-in "rate this meeting" star system. That's useless. You'll get a handful of ratings from people who either loved it or hated it, with no context. Survivorship bias in action: the people who suffered through a terrible format are probably the ones who left early and didn't stick around to rate it. You need qualitative data, but you have to force specificity.
Here's what I do. At the end of the meeting notes in Fellow, I append a simple, direct question in the shared document, like: "For next time, what's one agenda item we should shorten, and one we should expand?" Make people answer in the thread. It's not anonymous, which actually increases accountability and reduces drive-by hot takes. The key is linking feedback to a concrete future action. Vague "this was good/bad" feedback is just emotional venting.
Second, track latency. Not network latency—decision latency. Use Fellow's action item tracking to see how long it takes for decisions made in a meeting format to become closed tasks. If your fancy new "lightning decision jam" format produces 20 actions that languish for months, the format is failing, no matter how fun the meeting felt. The data is already in the tool; you're just not querying it.
Finally, rotate the feedback duty. Don't let the meeting lead or the most vocal advocate collect it. Their sample size of one is biased. Have a different participant each time be responsible for summarizing the feedback in the notes for the next session. This forces engagement with the process and surfaces differing perspectives. Otherwise, you're just measuring the organizer's satisfaction, which is pointless.
Anecdotes aren't data.
I run marketing for a 25-person SaaS company, and we've managed our customer meetings, internal stand-ups, and quarterly reviews in Fellow for about two years now. I actively use its feedback loop alongside our main email stack.
Here are the concrete aspects of building a feedback process on top of Fellow based on my experience:
* **Feedback Mechanism Fit:** Fellow's native "thumbs up/down" and rating prompts are built for speed, not insight. They target SMB teams who just want a quick pulse check. For mid-market teams needing actionable data, you must add structure outside those widgets, like mandated comment threads on notes.
* **Real Integration Effort:** Getting qualitative feedback into your CRM or a central dashboard takes work. We pipe meeting note URLs (with appended feedback questions) into ActiveCampaign via webhook for tracking, which required about two days of initial setup and occasional maintenance. It's not a click-connect integration.
* **Where the Process Breaks:** The biggest limitation is participant compliance. Even with a question in the notes, about 30% of attendees in my environment consistently skip it. You need a champion to gently enforce the habit, which Fellow can't automate. Anonymous feedback also isn't a true option without leaving the app.
* **Where It Clearly Wins:** Fellow's strength is contextual feedback. Having the full meeting agenda, notes, and action items right next to the feedback question provides unparalleled specificity. People reference exact talking points, which eliminates vague "it was too long" comments and turns them into "the project demo segment ran 15 minutes over."
My pick is to stick with Fellow, but only if your use case is a team already deep in its ecosystem and committed to manual process enforcement. If you need anonymous, automatically collected feedback that rolls up into analytics, tell us what your primary CRM is and how large your typical meeting is, as you'd likely need a more specialized survey tool integrated separately.
don't spam bro
Totally agree on forcing specificity with that direct question in the notes. I've done something similar but found you sometimes need to *rotate* the question to keep people engaged. One quarter I'll ask about agenda length, the next about the balance of updates vs. decision-making.
The anonymity point is interesting. We tried anonymous feedback via a separate poll for a bit, and the quality tanked - it was all surface-level complaints. Having names attached in the Fellow thread, like you said, makes people think twice before just venting. It turns feedback into a collaborative tweak instead of a complaint box.
Absolutely, forcing that specific question right into the notes is such a solid move. It takes the feedback out of a siloed widget and plants it directly in the artifact everyone already has to engage with.
I'd add that the *timing* of asking is just as crucial as the question itself. Asking right at the end of the notes, while the context is fresh, is great. But for recurring meetings, we've also had success adding the feedback question as the first note item *for the next meeting*. So when the template auto-creates the next week's doc, the first thing people see is, "Based on last week, what one change will make this hour more valuable?" It creates a continuous loop and frames it as prep work, not a post-mortem chore.
My only slight caveat is on anonymity - for very high-stakes or retro meetings about failures, having a truly safe channel outside Fellow can sometimes surface the raw, uncomfortable truths that named threads might stifle. But for the day-to-day format tweaks you're talking about, named accountability works wonders.
don't spam bro
Your point about "cargo-culting formats" is critical. Teams implement a "retrospective" or "planning" template because it's there, not because they've validated the ceremony fits their actual workflow. The process fix you describe - a concrete question in the notes - targets the root cause.
I'd extend your specificity principle to the data structure. Appending a free-text question gets you qualitative input, but you still have to manually parse it. To make it analyzable over time, we add a required one-word tag in brackets at the start of each reply. For example, "[AGENDA] shorten the client history review" or "[PACING] add a 5-minute buffer before decisions". This lets us run a simple script to extract and count tags from past meeting notes, turning anecdotes into a pivot table showing which format elements are consistently flagged.
The accountability from non-anonymity is a double-edged sword for junior staff. You might still need a separate, safe channel periodically to surface fundamental format mismatches they won't call out publicly.
Data is the only truth.
That's a smart approach, forcing the qualitative input directly into the artifact. Your point about linking feedback to a concrete future action is key - it transforms complaints into change requests.
I've implemented a similar tactic in our sprint retrospectives. We embed a feedback section in the template with a format that mirrors our pipeline's post-deployment approval: "What one process in this meeting should we **promote to stable**, and what one should we **roll back**?" It uses a devops mindset everyone understands, making the feedback feel like part of our workflow, not an administrative afterthought.
The non-anonymous thread does create accountability, though it can sometimes temper the initial honesty. We found pairing it with a quarterly, anonymous survey of aggregated themes helps surface any systemic issues people might still be hesitant to call out individually.
Commit early, deploy often, but always rollback-ready.
I love that "promote to stable / roll back" framing. It's a great example of borrowing language from your team's daily work to make feedback feel native, not like an extra chore.
Your point about pairing thread feedback with quarterly anonymous surveys is a smart hybrid model. We've done something similar, using the survey to check for patterns that no one is voicing in the open threads. It often flags things like recurring facilitators dominating the conversation, which folks are oddly hesitant to call out by name even in a constructive format.
The only watch-out we've seen is survey fatigue if you run them too often. Quarterly feels like the right cadence to keep them meaningful.
Raise the signal, lower the noise.
Exactly. The built-in star ratings are vanity metrics, not data.
Your method of appending a question to the notes is correct, but you need to lock it down. People will skip it. We make answering that mandatory field a gate for marking the meeting 'done' in our workflow. No completion, no sync to CRM.
Also, tie the feedback to an owner. "Shorten the client history review" is useless. "Assign to [name] to shorten client history review to 5 mins for next quarter" is a process.
Trust, but audit.
Making a field mandatory just creates checkbox fatigue. People will type "ok" or "n/a" to get past the gate. Then your process enforces garbage data, which is worse than no data.
And tying feedback to an owner assumes a benevolent manager. What happens when the feedback is "the assigned owner talks too much"? That action item goes nowhere. Ownership works for logistical fixes, not behavioral ones.
Don't panic, have a rollback plan.
You've nailed the core issue with cargo-culting templates. The star system is pure vanity metric, no different than tracking page views without conversion.
Your method of appending a direct question to the notes is the right start, but I'd push you further on the "concrete future action" part. It's not enough to ask what to shorten or expand. You have to tie the response directly to a measurable outcome for the *next* instance. We structure our question as, "What's one item we should shorten, and what specific, measurable outcome do we expect from reallocating that time?" This forces people to think beyond "this felt long" and justify the change with a predicted result, which we then verify in the following meeting's feedback. It turns anecdote into a mini-hypothesis test.
The non-anonymous thread does raise the quality, but watch for groupthink in long-running teams. We rotate the feedback facilitator role to prevent the most senior voice from setting the tone every time.
Oh, you're speaking my language. That move of appending a direct question right into the notes is pure gold because it hijacks the existing habit. People are already in there reading and adding comments, so you're not asking them to go to a different tool or context.
I've found the trick is to rotate the question format every few months, though. If you always ask "what to shorten/expand," you get rote answers after a while. Sometimes I'll flip it to "What was the single most valuable minute of this meeting, and why?" That forces a different kind of reflection and often highlights a hidden strength in the format you'd never think to ask about.
And you're dead right about non-anonymous replies. It turns feedback into a public, constructive conversation. I've seen it completely shift the tone from blame to problem-solving. The only caveat is you need a baseline of psychological safety on the team for it to work, otherwise people just stay silent.
hugo
The specificity in your question is correct, but it's structurally incomplete. You're asking for an adjustment to agenda items, but you haven't anchored that adjustment to the meeting's original purpose. Without that, you're just optimizing a potentially flawed format.
The question should be tripartite: "What's one item to shorten, one to expand, and how does this change better serve our meeting's goal to [e.g., make a decision, share risk]?" This ties the feedback loop directly to the intended outcome, preventing iterative refinements that simply polish a broken process.
Otherwise, you can perfectly execute a meeting that is perfectly useless.
Every dollar counts.
Agree completely that the star rating is useless noise. Forcing the question into the notes is the right move to get qualitative data.
But your method hinges on the facilitator remembering to append that question every single time. That's a process failure point. I automate it by embedding the question as the final section in the actual meeting template itself, so it's always there, baked into the structure. It removes the reliance on individual discipline.
—AF
Great point about automating it into the template - that's the only way to make it consistent. I'd take it a step further and have the template include a link to a quick, one-question poll about the meeting's effectiveness. That way you're not just relying on written comments; you get a quantifiable pulse check that's still tied directly to that specific meeting instance.
Keep it civil, keep it real.
That idea of turning feedback into a mini-hypothesis test is really clever, I've never thought of it that way. It makes the whole process feel more like an experiment than criticism.
But I'm curious about the verification step. When you say you verify the predicted result in the next meeting's feedback, how does that work exactly? Do you literally ask if the outcome happened, or do you just check if the meeting felt more effective? I can see it getting meta really fast.
Just my two cents.