'Tell me what happened and what it's preventing you from doing. I'll record the concern and confirm who will follow it through.' You can open with those words when a client raises a complaint. Your complaint handling process should move from hearing the concern to an owned action and a follow-up the client can understand.
You don't need a polished explanation of the cause before you acknowledge the problem. You do need to distinguish what the client has reported from what your team has verified. Keep that distinction in the record and in the words you send.
Hear the Complaint Without Arguing the Ticket
Let the client describe the effect before defending the work already done. Ask what they expected and what happened instead. Read the relevant ticket before asking them to repeat information your MSP already holds.
Use a question that identifies the complaint: 'Is your concern that the system still isn't working, that we haven't kept you informed, or both?' Adapt the choices to the facts they've described. A technical resolution and a communication failure need different actions, even when they concern the same ticket.
Record the complaint in your PSA or agreed client-management record and link it to the technical work. Keep the client's reported impact identifiable as their report. Don't turn a complaint about a delay into a confirmed breach of a promise before checking the actual commitment.
If the report needs an urgent incident response, start that process alongside the complaint record. Listening doesn't require postponing technical action. Keep the incident lead responsible for the incident and give the complaint its own communication owner where needed.
Acknowledge What You Understand
Do you need to acknowledge the complaint before you know the cause? Send the message below after filling in the facts and confirming the named owner. Replace the bracketed fields; don't send it as a form the client has to decode.
I'm sorry this has affected [the work the client described]. I understand your concern is [specific complaint]. I've recorded it against [reference], and [name] will coordinate the follow-through. We haven't confirmed [the unresolved cause or fact] yet. We'll update you through [agreed channel] at [confirmed time], even if the investigation is still open.
Keep that update time realistic and agreed with the person responsible. It is a communication commitment, not a repair deadline. If you can't confirm the owner immediately, say you're arranging ownership and give an update you can personally keep.
Make any apology fit what you know. You can acknowledge the disruption without inventing a technical diagnosis or agreeing to compensation you can't authorize. When your MSP has verified its own mistake, say what it was in plain language rather than hiding behind the template.
Name the Person Who Coordinates the Answer
Give the client a named contact for the complaint. The technical technician may stay responsible for the fault while an account owner or service lead coordinates the explanation. Make the division clear internally so neither person assumes the other is sending the update.
Tell the client: '[Name] is investigating the technical issue. I'll coordinate the complaint response and make sure you get the update we've agreed.' Use that wording only when it describes the arrangement you've actually made. A name in a message doesn't create capacity or authority.
Hand over the complaint with the client's concern and the commitments already made. Point the receiving person to the existing record. This is the handoff that lets the next conversation continue rather than restart.
I don't buy generic sales advice that tells a technician to do whatever makes the customer happy. At an MSP, the requested remedy might involve a production change, an expanded service, or a credit the technician cannot approve. Give them a route to the person who can decide, while they keep helping with the work.
Agree the Action and Keep the Update
Have the technical owner investigate the fault and the service lead check the service concern. They may share evidence, but one finding doesn't settle the other. A system working again doesn't establish that your communication met the agreement.
Say a client reports that they had to chase an update on a fault that is now resolved. Check the ticket history and the promised contact before replying. If the history confirms the missed update, acknowledge it and explain the specific follow-through you have assigned.
The reply could be: 'The technical issue is resolved, and our record shows we missed the update we agreed to send. [Name] is correcting the handoff that left that update unowned. I'll confirm the change with you at [agreed time].' That is proposed wording for that verified situation, not a claim about any particular client.
If the client requests a remedy outside the technician's authority, send: 'I can record that request and take it to [decision-maker]. I can't approve it myself, and I don't want to give you an answer that changes later.' Keep the decision open until the authorized person has made it.
When an update time arrives without an answer, keep the update. Say what has been checked and what remains unknown, then agree the next contact. Don't replace the missing answer with reassurance that the issue must be nearly finished.
Follow Up on the Remedy and the Client Outcome
Use the follow-up message after you can identify the actual work completed. Ask the affected person, or the client's agreed verifier, whether it achieved the intended result. Keep any remaining concern distinct from the original technical action.
We've completed [verified action] on [affected service]. Our check showed [specific result], and [remaining issue or limitation] is still open. Can you confirm whether [the affected work] now works as expected? [Name] owns the remaining action, and our next update is [agreed time and channel]. Please also tell me if the concern you raised about our service is still unresolved.
If nothing remains open, remove those fields and state the completed position accurately. Don't leave placeholder language implying further work. If the client says the remedy didn't solve the problem, record that answer and return it to the responsible owner.
Close the complaint through your agreed process with the outcome and any unresolved disagreement visible. Don't rewrite a disputed result as satisfied because the technical ticket is closed. Record the contact attempts if the client hasn't responded, using the agreed follow-up route.
Take any recurring delivery problem into a separate corrective action with an owner. Jack Lincourt describes reviewing historical tickets and technician approaches before documenting repeatable resolution steps. That's his practitioner account; it supports checking the underlying work before deciding that the only correction needed is another message template.
The model uses 95% annual retention as a planning assumption and calls for quarterly client reviews on margin and fit. Neither means this process will save every account or that a complaint proves poor fit. Use the record to inspect what happened, what your MSP changed, and what the client still needs decided.
Put the acknowledgement and follow-up messages where your technicians write client updates. Name who can take complaint ownership and who can authorize remedies. Then run an actual unresolved complaint through the steps, keeping the client's words and your verified findings separate all the way to the outcome.
mspoutpost.com/articles/a-complaint-handling-process-with-words-you-can-use
Written by Natalie Brandt
MSP Outpost publishes information, not legal, financial, insurance, tax or compliance advice, and reading it creates no professional relationship. For decisions about your business, talk to a qualified professional.