The best sign of good support is how rarely you need it
What "good customer support" actually means when you're running live qualitative research.
Picture this moment that service providers make support promises about: You have a live group running. The client is in the backroom, watching. The respondents are recruited, paid for, and sitting on screen, waiting for the next question. The clock is ticking, and there are no second takes. Then something fails.
That moment... not the demo, not the sales call... is where a platform's support is judged. And because that moment is so high-stakes, qual research platforms have settled on a tidy answer: to make live support mandatory or push it so hard that no buyer feels safe declining it. Buy the cover; always have a person standing by.
I understand the instinct. When the cost of failure is a ruined session with a paying client in attendance, paying for a safety net feels obviously rational. I won't pretend that's a foolish way to think. If I were buying, the fear would be real for me, too.
But as we build and run qual research platforms, I've come to believe that the reflex is worth questioning. Always-on support, sold as a default, provides reassurance but is also often compensating for something else: a product that needs babysitting. If a platform requires a member of staff shadowing every session, the honest question worth pondering is "Why would a well-designed platform need me to always buy support if it's actually designed for high stakes?"
Good support starts long before anything breaks down
On flowres.io, roughly 95% of projects run with no dedicated live support at all. On its own, that statistic should reassure no one. After all, buyers are right to ask whether it means that our users are simply more 'risk-tolerant.'
So, here's the harder number: some of our agency clients have run over 3,000 sessions on flowres.io in the past two years, without dedicated support. No pilot, no cautious toe-in-water trials. Thousands of real sessions, with real clients watching, that simply worked.
That isn't luck. There's a structural reason the number holds: it's because the work to make support unnecessary was done upfront. Once the user has a good sense of what is where on the platform, everything on the platform works as expected. So, we directed all our efforts in design and onboarding:
Product design: Most qual platforms run sessions on their own video conferencing infra. That means every participant has to learn an unfamiliar interface either beforehand or live, at the exact moment you can least afford friction. A confused participant becomes a support ticket, one that’s raised mid-session.
flowres.io doesn't work that way. Sessions run inside video tools people already use every day, so the participant's experience doesn't change at all. We've removed an entire (and most frequent) category of "support" before it can arise, simply by not asking participants to learn anything new or to participate.
Intentional onboarding: We onboard new users for free and tirelessly, without being stingy. If a client brings in a supplier or a partner to moderate, we onboard them too, at no extra cost, because a confused moderator is likely to cause a session to fail. For every new account, we join the first session ourselves to hand-hold.
Designed for DIY: We built flowres.io to be run by users, not by our support team. Sounds obvious, right? But it's actually a founding philosophy for us. We know a platform built for DIY use has to be legible enough for a user to accomplish the 'job' to be done, without struggling. It means every confusing screen, every unexplained button, every "Wait, where do I click?!" is a design failure we must fix, not a support call we charge for.
Most of what people call "support" is really the cost of a product that was never designed to be operated alone. We chose to absorb that cost upfront, in the design, rather than pass it to users as an ongoing line item. And that’s what "designed-in" support looks like.
The real test is what happens when things do break down?
Of course, things can still go wrong. The measure of support is what happens in the moments it's actually needed and how the platform responds.
Scenario 1
A new client, happy enough that he'd bought a significant number of credits in advance. Onboarding was done. Sessions were successfully conducted. First project completed, at high satisfaction levels.
Then suddenly we received a note. He had a very immediate and frustrating problem. We understood. Instead of opening a ticket and losing time, we asked the client to jump onto a screen-share call. Within ten minutes, the client and our tech lead were on a call together. The cause turned out to be a memory issue on the client's own MacBook; nothing to do with flowres.io at all. We helped him clear it anyway. The point is to own the outcome for clients, even in those awkward situations where the problem is not emanating at our end.
Scenario 2
A moderator working on an existing client's project couldn't see chat messages mid-session. They hadn't purchased our dedicated 24x5 live support. But, it didn't matter. The support team stepped in, alongside the tech team, to fix the issue on the spot.
In neither case did we respond with "Sorry, but that's beyond our scope." Because the operating principle is simple: things have to work for the client, irrespective of whether the problem lies at our end or the user's end. After all, the client experiences a session that either works or doesn't. Owning the responsibility of delivering a quality session every single time is what good support actually is.
But, this isn’t an ‘either-or’ argument, blatantly against buying dedicated support.
I want to be careful here, because it’s easy to misread all of the above as “Users don't need support." No, that's not the claim.
We understand that a live qualitative session with 30 client-side stakeholders present in the backroom is a genuinely high-stakes situation. Dedicated live support exists for exactly that. In such situations, the assurance that someone is on standby for the moments where you simply cannot afford to improvise can be much needed. At flowres.io, we do offer it, and for the right project it is indeed the right call.
Here's the part that sounds like a paradox but isn't: because our dedicated support is so rarely called on, the people who staff it are unusually good at it. They aren't script-readers fielding a queue of tickets. They're people who have personally run hundreds of sessions on flowres.io. They've sat in the PM’s chair, watched from the backroom, and handled the outlier cases firsthand. When you do buy dedicated support, you're not getting someone reading a troubleshooting flowchart. You're getting someone who has already done what you're about to do.
So the point isn't "Don't buy support." Instead, the point is that buying support should be a *deliberate* choice, not a reflex applied to every project by default. There's a difference between buying support because a particular session warrants it versus buying it every time just because the platform gave you no reason to trust that it would hold up on its own.
So when should you buy dedicated support? In my experience, it's worth it when one or more of these is true:
- The session is genuinely unrepeatable. A senior stakeholder you'll never get back in a room, a one-shot international panel across time zones, and a launch-critical study with no margin for a reschedule.
- The moderator is not onboarded to the platform, and this is a real project rather than a practice run; no first-session hand-holding has happened yet.
- The setup is unusually complex, e.g., multiple simultaneous groups, an intricate stimulus flow, or anything you haven't done on the platform before.
- The client is in the room, and the relationship is fragile or new. Sometimes you're not buying technical cover; you're buying the confidence to be fully present with your client, instead of half-watching the tech.
If none of those apply (i.e., if it's a familiar setup, a trained moderator, and a repeatable session), the honest answer is that you probably don't need it, and a good vendor will tell you so rather than sell it to you anyway. Sometimes, it could simply be clients reaching out to say they’re unable to hear backroom audio, where all support did was alert them about the accidentally pressed ‘Mute’ button at the client’s end.
That's the real tell. The next time you're evaluating a platform, retire the usual question. Don't ask, "Do you offer live support on every session?" Because that's easy to answer and tells you almost nothing. Ask instead: "How often do your clients actually need live support? When would you advise me *not* to buy it? And when the problem turns out not to be at your end, what do you do then?”
The answers to those three questions will tell you more about a vendor's support than any service tier ever will.
