We were on a weekly check-in with a client last week. Service Hub rollout. First team in the system, working through the early weeks of adoption. Standard stuff.
Except it wasn't standard. About ten minutes in, the team lead said, "We're getting frustrated. Yes. We are getting really frustrated."
What Happened
Here's the honest version. We'd been on weekly calls with this team since the rollout started. Every week, we asked for feedback. Every week, we asked what needed to change. And every week, the response was some version of "we're good" or "we're still looking at it."
Then, a few weeks in, the team lead said on a call: "We're getting frustrated. Yes. We are getting really frustrated.”
And we were caught off guard. Not because the feedback wasn't valid. It was. But because none of it had been surfaced before that moment. The issues she raised (properties from other teams cluttering their view, attachments not visible enough, permissions that needed adjusting) were all things we could have fixed in a day. If we'd known about them.
On top of that, there was one thing that was on us. The week before, we'd committed to building out reporting dashboards. It was discussed on the call. It was agreed upon. And then it didn't get done. That's a miss. Fully ours.
But the rest of the frustration had been building quietly, without us knowing. And that's the part worth talking about, because it happens all the time.
Step One: Own What You Missed
The reporting thing was a mistake. There's no spin on it. We said we'd do it, and we didn't. The first thing out of my mouth was: "That is totally my bad. We talked about that last week, it didn't get set as a task on our side, and we will get that remedied immediately."
No hedging. No "I think there was a miscommunication." No "let me look into what happened." I dropped it. We dropped it. Here's what we're doing about it.
This matters more than people realize. When a client is frustrated, the worst thing you can do is get defensive or vague. They don't need an explanation of your internal task management process. They need to hear: I hear you, that was on me, and here's what happens next.
Step Two: Hear the Frustration Without Taking It Personally
Here's the thing about client frustration during an implementation: it's almost never about you as a person. It's about the gap between what they expected and what they're experiencing.
This team lead cares deeply about her people. She knew that whatever she signed off on, the next team was going to inherit. She didn't want them to go through the same growing pains. She said it directly: "I don't want the next team to suffer."
That's not someone being difficult. That's someone being a good leader. And if you can hear that underneath the frustration, you can respond to what they actually need instead of reacting to how it feels.
What she needed wasn't for me to fix everything on the spot. She needed to know that her feedback was landing. That the things bothering her team were going to get addressed. That she wasn't shouting into a void.
Step Three: Validate, Redirect, and Be Honest
Here's what I said, and I think it's the thing that shifted the energy on the call.
"This feedback is fantastic. And definitely what we need. But the thing is, let me know before we're frustrated. If you want to send me an email, if you want to grab time on the calendar, put these things in the tracker. These are the exact sort of things that we're here to work through. We knew there were going to be things that weren't going to be just right. We're going to grow into them, and we're going to work on this together."
That's not a script. That's what I actually believe. But it's also a gentle redirect. We'd been on calls every week asking for exactly this feedback. The tracker existed. The email was always open. The issues that had been building for weeks could have been one-line items in a shared document that we knocked out between calls.
Part of the message was empathy. Part of it was accountability, on both sides. We're partners. That means we both have to show up.
I also needed to be honest about reality: "There are some things that we can't change, unfortunately. Like all software. Unless you're building from scratch, there are things in prebuilt software that we're not going to be able to change. That sucks. I get it."
Acknowledging the limitation without apologizing for it. That's important. You can't promise to fix things you can't fix. But you can be honest about what those things are and focus energy on what you can control.
Step Four: Get Specific About What's Next
Frustration without a path forward just stays frustration. So we got specific.
The attachments issue? We can't move them from the right side of the record (HubSpot limitation), but we can move them to the top so they're the first thing you see. And we can create a property on the left side that flags when a ticket has attachments, so nobody misses them.
The cluttered properties? We'll pull out the sections that belong to other teams. But we need the team to send us a list of exactly what they want to see, not what they want removed. Build toward what you need instead of away from what you don't.
The permissions issue where people couldn't see each other's attachments? That's a configuration fix. We'll handle it.
The reporting? Done by next week. No excuses.
Each frustration got a specific response. Not "we'll look into it." A real answer with a real timeline.
What I Learned (Again)
I've been doing this for fourteen years, and I still learn the same lessons over and over. Here are the ones from this call:
Set tasks for everything you commit to, on the call, before you hang up. I know this. I teach this. And I still missed it. I swear the task was there. Maybe it got bumped, deleted, accidentally closed. It doesn't matter. The point is it didn't get done, and the client doesn't need to know why. They need to know it's getting fixed. That's all that matters in the moment.
Create a culture where feedback isn't saved for the breaking point. We were on calls every week. We were asking the right questions. But the team wasn't surfacing issues until the frustration had compounded. That's not uncommon, especially with teams who are new to a system and aren't sure yet which problems are "real" and which ones they should just figure out on their own. The tracker exists for a reason. The mid-week emails are welcome for a reason. Part of our job during early adoption is making it so easy and so safe to flag things that people do it in the moment instead of collecting grievances for weeks.
Don't let "we knew there would be growing pains" become a dismissal. It's true. We did know. We said it on the training call. But when someone is in the growing pain, reminding them that you predicted it doesn't help. Acknowledge it, fix what you can, and keep moving.
The client who pushes back is the client who cares. The team lead on this call wasn't being difficult. She was holding us accountable because she wants the system to work. The clients who don't say anything are the ones who quietly stop using the tool and never tell you why. Give me the frustrated client who tells me what's wrong every single time.
The Bigger Picture
Being a consultant isn't always easy. There are calls where everything is smooth, the client is happy, and you feel great about the work. And then there are calls where someone is frustrated, you dropped the ball on something, and the conversation gets tense.
Both kinds of calls are the job.
The way you handle the hard ones is what defines the relationship. Not the deliverables. Not the dashboards. Not the perfectly configured pipeline. It's the moment where something went wrong and you showed up, owned it, and made it right.
By the end of this call, we had a plan. Reporting by next week. Property cleanup underway. Attachment visibility solved. Permissions updated. And a shared understanding that the feedback loop works best when it's used in real time, not saved up for a breaking point.
The team lead's last comment before we wrapped: "Let's get it right. Please."
That's not frustration anymore. That's partnership. And it's the kind of partnership that builds a system people actually trust.
If you're in the middle of an implementation that's hitting rough patches (or you've been sitting on frustrations you haven't surfaced yet), that's what we do.