• Replies 9 replies
  • Subscribers 2 subscribers
  • Views 0 views
  • Users 0 members are here
Options
Related

How do you handle customers who want a specific technician?

Paula Hendrix

Hi everyone — the team has been wrestling with this one lately and I'd love to hear how others are handling it.

We've got a growing number of customers (residential HVAC, mostly) who call in and specifically request "the guy who was here last time" or name a technician by name. Sometimes it's because they built rapport, sometimes it's a warranty callback and they want continuity, sometimes they just don't want to explain their setup to someone new.

The challenge: **our best technicians are also our busiest**, and accommodating these requests can throw off routing efficiency, create gaps in schedules, or delay other jobs. We've tried explaining that we can't guarantee specific techs, but that doesn't always land well with customers who feel like they're being passed around.

A few questions for the group:

  • Do you allow customer technician requests at all, or is it strictly "next available"?
  • When you do honor requests, how do you balance that against route efficiency?
  • Has anyone found a good way to set expectations upfront so this doesn't become a tension point?

The team wants to preserve relationships without letting customer preferences dictate our entire dispatch strategy. Curious what's working for others.

  • Paula, this is a classic operations tension and honestly I think a lot of teams handle it poorly by going all-or-nothing.

    Here's what we've landed on after some trial and error:

    We categorize requests into three buckets:

    • Technical continuity required — warranty callbacks, complex installs we documented specifically, anything where the original tech has institutional knowledge. We honor these, period.
    • Preference, not requirement — customer just liked someone. We'll note it, try to accommodate if it's within 48 hours and doesn't blow up the route, but we don't promise.
    • Specialized skill match — actually not a preference issue, just sounds like one. Customer thinks they want "Dave" but really they need someone certified on that equipment type.

    The key is training your dispatchers to diagnose which bucket fast. Most customers will accept "Dave's booked solid this week, but I'm sending Mike who actually did Dave's advanced training on this system" if you frame it right.

    Also: we added a "preferred technician" field in FieldPulse that's visible to dispatch but doesn't auto-assign. Lets us track the pattern without letting it drive the system.

  • Yeah we tried the "preferred tech" field... half the time customers don't remember the name right. "The tall guy with the beard" doesn't help.

    Our approach is simpler. We honor requests for callbacks on our own work only. Everything else is "we'll note your preference and do our best." Then we don't do our best unless it's convenient.

    Harsh? Maybe. But the alternative is your best tech doing 20-minute drives between scattered appointments while your new techs sit idle.

    One thing that does help: we tell customers upfront that techs rotate so they get exposed to our whole team's expertise. Frames it as a benefit, not a limitation.

  • Ray I love that framing! Thanks so much for sharing! We're definitely going to try that.

    We actually have a slightly different problem — we have two techs who are specifically requested by name because word got around they're the best, which means they're constantly overbooked and starting to burn out. Has anyone dealt with that? Do you cap how many "by request" jobs a tech can get? And how do you communicate that to customers without making it sound like we're hiding our good people?

    Also curious if anyone'susing the customer portal to let people see tech profiles or availability? I saw the beta announcement but wondering if it's actually helping with this issue or just creating more expectations to manage.

  • in reply to Deja Washington

    Deja so what we did was basically make me and the other senior guy "unavailable" for direct booking in the system for like two weeks to force the dispatcher to spread stuff around and honestly it worked pretty well customers got used to other techs and the new guys got better faster because they were doing harder stuff instead of just ridealongs

    the portal thing though idk we haven't turned that on yet seems like asking for trouble if people can see who's who and start making requests before they even call lol

  • Another way to think about this is through the lens of customer lifetime value rather than individual transaction efficiency.

    We've found that honoring a technician request for a customer in their second or third service year has measurable retention impact — something like 12% higher renewal on service agreements when we accommodate. The cost of a slightly suboptimal route for one job is often outweighed by the recurring revenue protected.

    That said, we also use this as a relationship management tool. When we can accommodate, we make sure the customer knows: "Normally our techs rotate, but since this is a callback on our work, I'm keeping you with Sarah." It reinforces that this is a favor, not a guarantee.

    For newer customers or one-off jobs, we stick to the rotation and frame it as "getting to know our team."

  • in my experience the customers who demand specific techs are usually the biggest headaches anyway

    had a guy last month insisted on "the young electrician who was here in june" — turned out he meant me, i'm just 47 and bald now, thanks

    but seriously half the time they want someone specific because they think they can get away with something. talked the last guy into a discount, want to try again. we flag those customers now

  • Love this thread — so many practical perspectives! This is exactly the kind of operational nuance we love seeing the community work through together.

    Quick note from our side: we're actually exploring some features in this space for 2025, including better visibility into technician history with specific customers and smarter routing that can optionally prioritize continuity without forcing it. Nothing committed yet, but the use cases you're describing are directly informing those conversations.

    In the meantime, the "preferred technician" field Gwen mentioned is probably your best bet for tracking — and if you haven't seen it, this post on rolling out to larger teams has some dispatcher training tips that might help with the expectation-setting piece.

    Keep the stories coming — real examples help us build better.

  • We don't honor requests. Full stop. Customers get assigned based on availability, skill match, and route efficiency.

    My team can't move forward if we're rearranging schedules every time someone liked a personality. We have 34 techs. The math doesn't work.

    What we do offer: callback guarantee. If it's our work, we fix it free no matter who shows up. That eliminates 80% of the tension.

  • Thanks everyone — genuinely helpful range of perspectives here.

    Brandon, I hear you on the math. We're at 22 techs and I can feel us approaching that inflection point where flexibility becomes chaos.

    Nadia, the CLV framing is useful — I'm going to pull some data on whether our "request honored" customers actually do renew at higher rates. If they do, that justifies building some inefficiency into the model.

    Gwen, the three-bucket diagnostic is going straight into our dispatcher training. That's exactly the kind of operational clarity we needed.

    And Carla — appreciate you jumping in. Would love to see continuity scoring or "last tech served" surfaced more prominently in routing if that ends up on the roadmap.

    Will update the team and report back if we land on something that sticks.