What Does It Mean to Solicit Feedback and Why Can’t Your PSA Do It for You?

Most definitions of soliciting feedback are written for large HR teams. For a managed service provider, the definition needs to be specific and practical. 

Soliciting feedback means creating a structured, recurring mechanism to collect honest signal from technicians. Not waiting for them to volunteer it through an open-door policy. In an MSP, this is distinct from everything your PSA already tracks: 

• CSAT measures client sentiment about your service output 

• Ticket resolution data measures speed and volume 

• Annual reviews measure past performance 

None of this capture what a technician actually thinks about their role, their manager, or their career trajectory right now. The operative word is “solicit.” Active, systematic, documented collection. Not passive receipt of complaints. 

MSP technicians’ default to quiet disengagement before resignation, a pattern well-documented in r/msp communities where owners repeatedly describe exits as “out of nowhere.” That is not a communication failure. It is a signal infrastructure failure. PSA data measures output. Solicited feedback captures attitude, trajectory, and team health before they become retention events. 

This is not a conversation problem. It is a structural signal failure. Understanding the specific conditions that suppress honest feedback is more useful than any template. 

On-call culture, client-site isolation, and dispatcher-mediated work mean many technicians operate with limited direct manager contact. The conditions for voluntary feedback structurally do not exist in most MSP environments. Conflict aversion is documented across IT worker populations. Gallup’s State of the Global Workplace 2023 found only 32% of U.S. employees are engaged, with IT SMBs consistently below that average. Disengaged workers rarely self-report. 

Fear of professional consequence suppresses honest feedback further in small teams where the owner is also the hiring and firing decision-maker. The open-door policy assumes technicians will walk through it. Most will not. 

Consider this archetype from the MSP community: a 15-person break-fix MSP transitioning to managed services lost three technicians within six months. All three cited undefined role expectations in exit interviews. None had raised concerns during employment. The open door was there. Nobody used it.

A working feedback system is not a survey sent twice a year. It has four components running together. Remove any one of them and the system breaks. 

• Recurring cadence. R/msp patterns support quarterly structured check-ins plus monthly lightweight pulse questions of three to five questions as the minimum viable signal frequency for MSPs under 50 people. Annual-only cycles are nearly universal in sub-20-person MSPs and nearly universally cited as insufficient. 

• Standardised questions. Not open-ended Slack messages. Specific, consistent questions asked the same way each cycle so responses are comparable over time. 

• Documented responses. Not memory. Written records that create an attitudinal data trail sitting alongside your PSA performance data. 

• A visible action loop. This is where most systems collapse. When technicians complete two or three feedback cycles and see no visible change, completion rates drop and the process gets written off as performative. Feedback must demonstrably influence decisions or it stops generating honest signal. 

PSA-adjacent workarounds, appending questions to ticket closures in ConnectWise or Autotask, or using HaloPSA notes fields for performance context, are not built for people data. They fail the documentation and action-loop requirements from the start. The 25-person MSP that switched to Google Forms saw survey completion drop below 30% after two cycles with no visible response to feedback. Technicians openly called the surveys “performative” in team Slack. Kaseya’s MSP Benchmark Survey 2023 confirms structured internal feedback programs are among the least formalised processes in MSP operations, despite workforce development ranking in the top five operational concerns.

Most MSP owners believe they are already do soliciting feedback. Annual reviews, EOS Quarterly Conversations, ad hoc Slack check-ins. None of these constitute structured feedback solicitation. 

Annual reviews are backward-looking, high-stakes, and infrequent. They evaluate past performance, not current engagement trajectory. By the time a retention risk surfaces at an annual review, that technician has typically been interviewing for 60 to 90 days. 

EOS Quarterly Conversations serve an accountability function, not a signal-gathering one. They confirm whether someone is in the right seat. They do not surface early-stage disengagement. MSP owners running L10s cite a specific failure: inability to move people issues from Discuss to Solve without a documented feedback trail. The Quarterly Conversation does not produce that trail. 

Soliciting feedback is a separate, forward-looking practice run on a recurring cadence specifically to capture current team health before it becomes a retention event.

The cost is invisible until a departure, dispute, or client escalation forces the calculation. 

CompTIA reports 13 to 19% annual technician turnover in IT services. SHRM benchmarks replacement cost at 50 to 200% of annual salary. For an L2 technician at $55,000, that is $27,500 to $110,000 per departure in recruiting, onboarding, and productivity loss. None of that figure appears in any PSA report. 

Beyond headcount cost, three consequences compound quietly: 

1.EOS documentation gap. A 40-person MSP running EOS recycled the same people issue through three consecutive L10 meetings because no feedback trail existed. The team lead eventually self-selected out, but three quarters of L10 time had been spent circling an undocumented problem that could not move from Discuss to Solve. 

2. Legal exposure. Inconsistent feedback documentation creates liability in termination disputes. If records exist for some employees but not others, or show no documented performance concerns before a termination, HR legal risk increases materially in California, New York, and Canadian jurisdictions. A contemporaneous feedback trail supports HR decisions and provides defensible documentation. 

3. Client impact. MSPs measure CSAT externally but rarely correlate it with internal tech sentiment. Behaviours driving client churn are often visible in internal feedback data months before they surface in a CSAT drop. Without that internal signal, you are always reacting to the complaint, never preventing it. 

One additional signal worth noting for 2025 and 2026: as PSA-embedded AI tools like ConnectWise Sidekick automate tier-1 ticket resolution, technician roles shift toward higher-complexity, client-relationship-intensive work. Attitudinal and engagement signals become more operationally critical as the output metrics managers historically relied on narrow in scope.

These are not invented objections. They are documented beliefs in Channel Futures MSP workforce coverage and r/msp community discussion. 

Myth 1: “My techs will tell me if something is wrong.” The most common and most dangerous. Technicians default to quiet disengagement before resignation. The open-door policy fails because it requires the technician to initiate a conversation that carries professional risk in a small team where the owner controls their employment. 

Myth 2: “We are too small to need a formal process.” Sub-20-person MSPs have the least redundancy to absorb a surprise departure. A 12-person MSP losing one L2 technician does not lose 8% of headcount. It loses a tier. Informality is a privilege of scale that small MSPs cannot afford. 

Myth 3: “Annual reviews cover it.” Annual reviews are backward-looking and high-stakes. By the time a retention risk surfaces at an annual review, the technician has been interviewing elsewhere for 60 to 90 days. The review confirms the problem. It does not prevent it. 

Your PSA tells you what your team delivers. It does not tell you how they feel about delivering it or whether they plan to stay. That signal does not appear in ticket data, CSAT scores, or annual reviews. It only surfaces when you build a system designed to produce it. 

Soliciting feedback is not a soft HR exercise. For MSP owners managing lean teams with no safety net for surprise departures, it is one of the most operationally important practices you can formalise. 

Team GPS gives managed service providers a built-in feedback engine designed for service delivery teams without HR departments, with recurring check-ins, pulse questions, manager dashboards, and a documented signal trail that works alongside your existing PSA workflow. See how MSP teams use it to surface retention risk before it becomes a resignation. 

Q. What is the difference between soliciting feedback and asking for feedback?

A. Soliciting feedback is structured, proactive, and documented with a defined cadence and standardised questions. Asking for feedback is informal and ad hoc, producing unreliable signal because technicians answer based on the moment and the perceived safety of honesty.

Q. How often should an MSP solicit feedback from technicians?

A. A minimum of quarterly structured check-ins combined with a monthly lightweight pulse of three to five questions. Annual-only cycles are nearly universally cited as insufficient in sub-20-person MSPs because the retention window for a disengaged technician has typically already closed by the time the annual review occurs.

Q. Does soliciting feedback create legal risk for MSP owners?

A. Structured, consistently documented feedback solicitation reduces legal risk rather than creating it. The risk comes from inconsistent documentation, which increases liability in termination disputes particularly in California, New York, and Canadian jurisdictions.