Skip to content
Log in
— Episode 9 · 40 min

Premier support that pays for itself

Miles Goldstein has built premium support programs at several B2B SaaS companies, most recently running mission-critical support for 35 global enterprise accounts worth over $200m in ARR at 98% CSAT. He breaks the program into four steps and is specific about the trade-offs at each one.

April 15, 2025 · Jen Weaver with Miles Goldstein, Support executive

— Takeaways —

What you’ll learn from this episode

  • Decide dedicated or designated first. Dedicated gives you deep account knowledge and a single owner; designated scales better and survives absences, at the cost of intimacy.
  • Sales, finance, product, and marketing all have to be bought in before you price it, and the price has to be non-negotiable once set.
  • The ROI case is retention plus CSAT. His team ran 98% against a company average in the high 80s, because the relationship already exists when something breaks.
  • Hire for soft skills and teach the technical baseline, not the reverse. The most technically knowledgeable person is often the wrong fit.
  • Interview for storytelling. Ask about a problem they could not solve, and listen for whether they engaged engineering, collected data, and walked the customer through it.
  • Your tooling has to support it before launch — premier flagging, direct routing, after-hours fallback, SLA alerts. Good program design cannot survive a help desk that cannot route.
  • Trial with three to five friendly accounts. If you miss on the first attempt it is hard to get a second shot internally.
— Chapters —
  1. 0:00Introduction
  2. 2:05When premier support becomes necessary
  3. 4:10Dedicated versus designated
  4. 6:16Proactive support and the relationship
  5. 8:21Fee-based or free, and who must be on board
  6. 10:26The ROI — retention and CSAT
  7. 12:31Staffing models and forecasting
  8. 14:36What the ideal candidate looks like
  9. 16:41Hire for soft skills, teach the technical
  10. 18:47Interviewing for storytelling
  11. 20:52Dedicated and designated in practice
  12. 22:58Coverage hours and following the sun
  13. 25:03Recap of steps one and two
  14. 27:08Step three — systems and tooling
  15. 29:13Portals, email, and why not chat
  16. 31:19Routing, flagging, and SLA alerts
  17. 33:24Step four — the trial launch
  18. 35:29Measuring success
  19. 37:35Why the program has to stay dynamic
  20. 39:41Recap
— Transcript —

Transcribed from the recording and edited for readability — false starts removed, product and proper names corrected.

Miles Goldstein Customer satisfaction for my team was 98%, because we've got that relationship.

There's an old story. If a customer's trying to go from point A to point B and they get there successfully, they're happy. If they go and they fall into a ditch, they're not happy. If they fall into a ditch and someone pulls them out — the support team, or the CSM, or the account team — that customer is ecstatic, because they know you will be there for them if they have a problem.

So things like this get the higher customer satisfaction ratings, because sooner or later an account that large is going to have a unique and expensive problem. This is the real world, that stuff happens. You're there to get them out of the ditch, and that's the heart of the relationship. Now there's a trust relationship.

Jen Weaver Welcome back to Live Chat with Jen Weaver, the podcast for support teams with tactical tips and actionable playbooks.

In this episode we're talking about premier support — when it's time to introduce a next-level tier of support, and how to roll it out well. Our guest is Miles Goldstein, a longtime support executive who built premium support programs at companies like Okta and Amobee.

Why should we listen to him? Well, at Okta, Miles led mission-critical support for 35-plus global enterprise clients with over $200 million in ARR, achieving 98% CSAT while managing a remote team across North America, Europe, Australia, and Japan. In short, he's done this before, he's been in the trenches, and he's here to share how to build a program that drives retention and earns executive buy-in.

As always, this episode is sponsored by Supportman, the tool that connects Intercom to Slack and leverages AI to provide your support agents with real-time feedback and surface issues as they happen. Learn more at supportman.io, and let's jump right into it.

I'm here with Miles Goldstein, and I would just love for you to go ahead and introduce yourself.

Miles Hi, good morning. I'm Miles Goldstein. I've spent my whole career building and leading global tech support organizations for B2B companies, in the last 20 years mostly SaaS companies. I've run a lot of programs, I've run global support, and I'm excited to talk about premier support, which I've done at several companies along the way.

Jen You said you've implemented premium support at a few companies, so it sounds like you may have a sense of the typical way that this shows up for teams. When does it — what's step zero? When does it become apparent that this is necessary?

Miles First, it becomes apparent when you have a segmented customer base. You've got your couple of customers who are just way top-end — your top 10 customers or your top 10% of customers — who have needs beyond your normal customers. Their ARR is typically much — I shouldn't use acronyms — their annual recurring revenue is usually much higher. They're the ones where, if you can save one customer, you're saving this one.

Once you get there, you've got to decide what it is they need that's different from what you're already offering. Are you going to make your standard support offering better for everybody, which is always a good idea? Or are there specific things that this group needs? And along with that, are they willing to pay for it?

Jen That makes sense. Something like premium support, where you're going to have a wide difference between your lowest revenue customers and your highest revenue customers, would be where you would eventually segment them out into a different category.

Could you talk to me about the very first steps of implementing this, if I'm a support manager who has never done this before?

Miles First, you have to decide really what it is you want. I came up with an analogy this morning about buying a car. Do you want a new car or a used car? Do you want gas or electric? Do you want a coupe, a sedan, an SUV? With premium support, there are several choices you have to make along the way.

One of the ones that I lead with is whether it's a dedicated resource or a designated resource. The difference there is, dedicated means one or two assigned accounts per engineer. So I'm full-time supporting customer X, or I've got X and Y. As opposed to designated, which usually means it's a named resource — all of your cases are going to go to Miles, but Miles doesn't handle just your account, he handles several accounts. Or it may be a small major-accounts team that's handling it. You're always getting the same small group of people, and they've got their own special tools and rules and everything else.

You've got to decide what level you want to go to. The advantage of dedicated is you get a really strong relationship and really customer-specific knowledge of what's going on. The con is scalability — and if somebody's absent, you've got to cover with somebody who's not as familiar with the account. With designated you get a much more scalable model, it's more robust, but it's less focused than a single resource would provide.

As a dedicated resource, I know what you're trying to accomplish with my tool. It's up there with customer success — they're two legs of the same stool. The customer's use of the product, you live and breathe. When they say the flux capacitor's out, you know what they mean, how they're using it, why they're using it, why they've made their implementation decisions, and your support is geared towards that.

You're not asking the standard 20 questions. What's happening, what's not happening, what's the last time it happened, why did you do this, why did you make that decision, have you thought about upgrading? It saves a lot of that time, which a lot of customers get frustrated by. Normal support is an investigative chore, and with someone you're not familiar with you've got to ask, is it turned on, is it plugged in, are you seeing the green light — even though your customer is sometimes far, far more knowledgeable than you.

So this saves that. You have that relationship, you have that knowledge. Customers who spend a lot on your product or your service don't want to encounter that.

Jen "Did you unplug it first" support.

Miles Exactly. You're part of their team, you understand what's going on. And especially if it's dedicated, you've only got one or two accounts — you're talking to them every day. It's not six months of silence and "oh by the way, now we've got a problem." You know what's happening, you know the decisions, you know what their plans are for the next 90 days and how they're getting there.

They're doing proactive support because of that. Okay, you're rolling out in 90 days, we've got this big release schedule — let's see if we can work with product and alter the dates. We don't want to roll out the day before you go live with your new thing, because one of us is going to break something. It allows you to be proactive.

Another set of decisions you've got to make up front is whether it's fee-based or free. Now granted, we're talking about your highest value customers, so implicitly you're making the most money off of them. You get to decide whether they want to invest in it, but a dedicated resource has a very high price tag.

If I'm talking to a $5 million account, asking them for $300,000 to pay for that resource — yes, that's $300,000, I can't write that check. But compared to the rest of the product offering that they're buying, it's usually a good deal. And even for that $5 million, they're usually getting heavy discounting. So keeping you as the partner intact — you need to stay whole, you need to be able to provide that resource.

You've got to decide whether you're cooking it into your license costs, or whether this is an elite offering and you've got to charge for it. You've got to pay for it somehow.

Jen I wanted to go back to one thing that you said earlier, about whether or not you're going to charge for your premium support. What executive teams or other teams would you work with to determine that as you're creating your premium support offering?

Miles Sales, finance, and product all have to be involved.

Product has to be involved because the company has a look and a feel, a voice. My marketing materials for the program go through product and marketing so that they're consistent with the message we're trying to give. If we're going to say this is a premium offering that costs $300,000, marketing and product have to be on board with "we are packaging this as a high-end option." It's not available if you've got a $10,000 contract — you don't get this level of service, and under a $10,000 contract you can't afford this level of service, don't expect it.

Sales has to be on board — whether or not they're getting commission on it, because they should get paid for things they sell. You want to make sure that if you put that price, the price itself is non-negotiable. Don't throw that in. Or if you're trying to bundle things for the customer, say, "And with all this, you should add this on because it works so well."

But they've got to be on board. You can't have them saying, "Why am I trying to sell this thing if I'm not getting comp, or if I'm going to alienate my customer? I'm about to bring in half a million dollars, why am I talking about paying for support?"

So everyone's got to be on board, and that starts at the top. Your CRO, your CFO, they've got to be there. If an individual sales rep doesn't buy into it but the CRO is very much on board, that becomes a performance issue. It's no longer the glory of support packaging that program.

Jen You're a support leader in this conversation with marketing and finance and product, and there's got to be some data that you need to bring to this conversation about what the satisfaction has been from the customer, how these top accounts are performing. What do you bring to that conversation? What do you prepare?

Miles The things for the ROI tend to be the retention rate — which, especially since you're talking about your high value customers, retention matters. Very important. If I'm helping us keep that $5 million account, you can't afford to lose that. There's a lot of work that has to go into replacing that kind of revenue.

And the other thing is customer satisfaction. My last team — our customer satisfaction for the company overall was in the high 80s, which is good, that's a very good number. Customer satisfaction for my team was 98%, because we've got that relationship.

There's an old story. If a customer's trying to go from point A to point B and they get there successfully, they're happy. If they fall into a ditch, they're not happy. If they fall into a ditch and someone pulls them out — the support team, or the CSM, or the account team — that customer is ecstatic, because they know you will be there for them if they have a problem.

So things like this get the higher customer satisfaction ratings, because sooner or later an account that large is going to have a unique and expensive problem. This is the real world, that stuff happens. You're there to get them out of the ditch, and that's the heart of the relationship. Now there's a trust relationship. Now there's knowing that you are a part of the team. And that CSAT goes up, and that retention goes up.

Yeah, I can change to another vendor who's got a lower license fee, but I don't know that they're going to get me out of that ditch. And that's the ROI — the retention and the CSAT.

Jen It makes total sense. Are there staffing numbers, or information about what it would cost to upskill some of your existing specialists or add new specialists to be able to achieve the goal? It seems like finance would definitely need to know what those costs would be.

Miles I've had a couple of different staffing models. In my last role, when I first got there it was just-in-time staffing, which meant that if a sales rep sold the PO, the contract said I've got 90 days to hire somebody before the contract starts.

And even that was unrealistic, because it took me 90 days in most cases to find someone who was qualified, and another 90 days to train them. It depends on your product and on your candidate pool. But during that second 90 days I would typically give that account to one of my existing people to ramp them up, get to know about them. And yes, that means my person was handling more than 100% of their identified account load. It was a risk that as a company they chose to take.

In later years there, I got it into the budget. They said, "Oh, you can't have this just-in-time head, it wasn't in your VP's budget." Okay, well, now let's do better forecasting. So now we're forecasting I want to add two or three people every quarter — a person a month. Put that into the budget, let's get the hiring pipeline going. And if we're hiring at that rate and truly growing at that rate, my 90 days for hiring goes down to 45.

I was hiring at a pretty good clip a couple of summers ago. We had the training optimized — here's what happens on day one, here's what happens on week one, everyone gets a mentor from within the team, here's the product things — and we had that down to about 60 days. So we basically cut our ramp-up time in half by doing better forecasting, and as the team got larger, having a better internal process for onboarding.

That's a luxury when you're first kicking this off. You tend to recruit a couple of the best people from normal support delivery. Make sure you get a really good relationship there, because you can't be stealing their people, especially their best people. And sometimes their best people aren't the right people for this kind of offering.

The technically most knowledgeable person might not have the soft skills and the time management skills and other skills necessary for this. You want someone who's going to be able to be a diplomat with that customer. Someone who's going to be able to follow up on their commitments, and be able to say, "I don't know this thing, but I will go find out, because I'm that support concierge. I want to get your answer for you. One call and you're done" — even if I'm not the person with the answer right now.

So it's not always recruiting just the smartest person out of support. It's recruiting the best person with the best customer skills and other skills. It really looks in that regard more like a CSM who's got the technical skills but has the account management skills as well.

Jen So what are the characteristics of the ideal candidate for a premium support role?

Miles A technical background. It's still a technical support role. Whereas someone who's worked retail is going to have great people skills — if they've never thought about enterprise software, I can't teach them how these 12 servers together all work to get a front end and a back end. They have to have some knowledge coming in, or be trainable. Show me transferable skills.

Sometimes I've hired former system administrators because they understand how the technology works, so they're just learning the product — if they come in again with those soft skills.

Sometimes I've brought people from CSM into my team, or my team growing out into CSM. It's two sides of the same coin. "I like the business aspects of my job more, I'm going to move to CSM." "I really like the puzzle solving of the technical problems, I'm going to go over to the support side." But they've got those skills.

So I look for the communication skills, the time management skills, the ability to communicate good news or bad news, the ability to think three steps ahead. These are difficult things because they're all very subjective, a lot of that is not objective, I get that. But for this kind of role it's typically somebody who has been face to face with customers, has been on a support line or in the field.

Somebody who — I joke about retail — somebody who's worked retail and then got into tech for two years. I was in retail in high school. Many of us were. There are skills you pick up there that are wonderful. If you can look face to face with a retail customer, you can look face to face with a CIO and tell them good or bad news.

Jen Is it easier to hire for technical skills and build soft skills, or hire for soft skills and build technical skills?

Miles Definitely the latter, because soft skills are a personality thing. Either you're type A or not, either you're detail oriented or you're relationship oriented.

Some of my best people have just been naturals. One of my lead guys at my last job, he had the bedside manner of a pediatrician. You just can't beat that. I can't teach that. I can mentor it, I can model it, I can coach it — but either you're a people person or you're a misanthrope. I can't teach out misanthropy.

The technical skills, they have to have the baseline. If we're going to say here's what the front end is, here's what the back end is, here's how you get to the database — I want at least those concepts to make sense. I want them to understand the trip across the network from the user's terminal or phone or whatever, and how it bounces off all these different things. I can show them a diagram, but they have to understand why those boxes are in that diagram.

But again, the soft skills are harder to teach. They have to come in with those, and they have to have a baseline of transferable skills for the technology.

Jen What are some of those anecdotes about your very best staffing situations, where you found somebody who really fit this role?

Miles There have been good hires and bad hires. I had one bad hire — let's start there — who I brought in who had all the technical skills, but throughout his onboarding I kept getting feedback from his mentor that he just wasn't keeping up. And at 90 days we had a mutual agreement, he left. He wasn't the right person. He was technically smart, but he just wasn't following the program.

On the other hand, as I alluded to, a couple of summers ago I actually doubled the size of my team. I had to hire 12 people over two months, and that was a riot. But we ended up getting multiple people on the team involved in bringing people in. And some of these people were just amazing, they got it.

And because we were doing so many, we knew in our interview process what the red flags were and what the key things were. It was very subjective, but we agreed on that subjectivity. This person knows how to talk to a high-level customer about a high-level problem. This person knows how to seek out help from engineering, and how to get engineering to cooperate.

In support we often have to beg and plead to get attention — "oh, my bug, you've got to look at my bug." But I've gotten engineers on repeated daily calls with customers because we've built that relationship. And it's the person on my team who has built that relationship across those departments. It's that person on my team who's built that relationship with the CSM.

So we go back to those soft skills during the interview. That's what I'm looking for, primarily soft skills. I've got technical people on my team who'll do the drill down — can this person speak HTTP? I don't know.

I don't try to intimidate them, but I say, here's stuff on your resume, explain it to me. I want to know, ultimately, did they do what they said they did, or were they in the room and someone else was doing it?

And I'll ask about difficult customer problems. Tell me about the problem you couldn't solve, that kind of thing. "All right, well, there was this crash that kept happening, and I did this, and I went out there and I worked with the customer on that, and we collected these logs, and I brought in engineering."

Cool. That person said all of the key points. I met with the customer, I brought in engineering, I collected data. That person understands how to do the job, and they explained it to me in a calm, story-like manner.

Telling stories — this is why I like doing a podcast like this, I'm a storyteller, you can tell. I want people to tell me a story when I'm asking them these kinds of questions. "Did you ever do this, yes or no?" Again, goes to those binary support answers. But yeah — here's what happened, when. And that's what I look for in those candidates.

Can you tell the customer a story? Bring them on board, have them take that journey with you. "Your bug's not being fixed today. I spoke to engineering, in all likelihood they're targeting Friday, but we know that they often miss that. So probably by Monday I'll have an update. If they fixed it by Monday, I'll have it to you by Wednesday." Give them the story. Don't just say, "I checked on it, I checked on it, I checked on it."

And if I can see that in an interview, if I can see that in a person I'm raising through the ranks from junior to senior to team lead, I'm looking for that kind of thing — that relationship building and that storytelling. And again, I have the people on my team check those tech skills.

Jen Storytelling, that's brilliant. I think that gives us some real concrete things to look at when hiring for these kinds of premium support roles.

You mentioned dedicated versus designated. From what you're saying, what I'm getting is dedicated support means I'm a support specialist and I am the one person that Acme Corp turns to for their needs with our product.

Miles Exactly.

Jen And so how would you describe designated?

Miles Dedicated is the relationship. I'm the face, I'm the single throat to choke — just like the account rep does, just like the CSM does. Again, three legs of the stool, but they're each that single throat to choke.

Designated means I'm part of a team supporting you, as part of a group of customers. So it's more the direct line to a senior resource, and this person is a member of my team. I'm always getting one of the same three, four, five people, and depending on the part of the product — Billy always handles the front end, and Sally always handles the back end, and Rod over there handles reporting.

It might be that we've got expertise within that special focus team, but I know I'm always getting a specialist. And with this part of the product, I'm talking to that specialist enough times over the course of a year that they know who I am, they know what my account is. They're not asking those 20 questions every time. You're still getting around the 20 questions and building relationship, but it's slower and more multifaceted. It's a team — you're playing first base, I'm playing third base, and it depends where that ball is going today.

Jen And it sounds like that depends too on what kind of hours you're offering. If you're offering 24/7 support, that person is not always going to be able to get their dedicated support specialist.

Miles Yeah, and that has created some interesting — I'm on a variety of Slack communities where we talk about stuff like this all the time.

In my last offering, it was during the customer's main business hours. If your HQ is on the east coast, US, you get Eastern US time. If your HQ is in London, you're getting British time or whatever. If you're calling after hours, the entitlement is to standard support — and you still get flagged as a premium customer, you still get better SLAs, I'm still going to follow up on your issue in the morning when I come in.

And for a couple of my accounts — there were three that were at the top of my 35 — for them, after hours, I had staff in all three time zones. So if it's from Monday in Europe until Friday in APAC, I'll follow the sun within my team for these couple of accounts. They were global accounts.

And in one case I actually doubled their fee and gave them a person on each continent for twice that fee. It was a very fair deal. They agreed — "you're right, we need this, we've got people in Poland and they can't wait for somebody in Florida to wake up." Okay, you're right, let me give you my guy who's in London.

Jen So it's dedicated support, but with multiple specialists covering all the time zones.

Miles The Florida person owned the account, but I gave them direct access to the other two people, APAC and Europe, because of the nature of that relationship. I want to make sure that nobody ever dropped the ball.

And with one of these accounts they had even special things — usually if there was an incident, a server-down kind of thing, we had a communication process and we reached out to our customers. But two of those customers had even above and beyond that, where we were on calls and on Slack communicating with them constantly rather than giving them updates. And a need to have a global team to pass the baton on that.

So again, isolating your very topmost customers, and what do they need that differentiates. Protect that $5 million, $10 million account. There are things you will do. I often ask, how much will you pay to save an account? Well, in this case I paid by giving him extra access, because this was an account we needed to make sure was never at risk.

Jen That's a wealth of information. I just want to review — step one for this process is confirming your market needs, and step two is identifying your staffing model. Anything else about those two steps you want to cover before we move to the next step?

Miles The needs and the model, and understanding — do you want to play all four of those roles? Dedicated versus designated, fee-based or free. Which of the four or five roles I identified do you want to make sure are part of that? And the market, if you do the survey right, will tell you those. So that rolls up into what I had called step one.

And then the staffing model is step two. Figure out how you're going to look for those candidates. What's the ratio of accounts to candidates? How are you going to get in front of this? How quickly do you want to ramp this program up?

The next step is you've got to have the systems to support it. Do you need changes? In my systems I needed to make sure they were flagged as premier accounts. I needed to make sure there was routing built in that wasn't going to a product-based queue, that was going directly to the person on my team. I needed to have workforce management software in place so that if this person was out, it routed to the other person — or after hours it was routing to standard support.

So you need to make sure your tools can support this. If your tools aren't going to support it, you're going to fail. It doesn't matter how well designed the program is if the customers can't get where they need to go.

Jen For premium support, do you feel that it's always necessary to have phone support, or do email and chat suffice?

Miles I've always been a fan of email support, and here's why. We're talking about enterprise applications. You call and say, "I'm getting this weird error message." "Oh, what does it say?" And the person reads it off the screen — and I can tell you from God knows how many years of experience, people never read what's on the screen. Their mind makes up words. It says "failure." Now what kind of failure? What event? On and on.

With email you get screen grabs, you get to send technical information, you get to send logs, attachments. To me that's just wonderful. If you can do a screen share session, that works great too, I can see it happening.

As far as things like chat, I've never been a fan of real chat. But for certain accounts I've set up Slack channels where we can talk to them over Slack. To me the requirement has always been: if you're logging a new issue, log it through email or through a portal.

I love having customer portals. A portal is even better than email, because you can put a knowledge base on there. They can search the knowledge base, they can get other answers while waiting for you. But log a case through the portal or through email, and then we can exchange notes or have discussions on Slack or chat — but don't log your case there. It's not a real-time mechanism, it's not going to tell me what's going on unless you hook up certain integrations.

Salesforce and Slack do have integrations where you can send some stuff back and forth. I was using Salesforce at my last company, and we set it up so Salesforce would send a message to the Slack channel when a case was logged. So if you were watching Slack, you saw that. Other people, like the CSM who are watching that channel, don't have to watch Salesforce and don't have to watch email. Who's interested in Acme Corp? Acme Corp, I can just see the logged case, I can see what's going on with that. So those kinds of tools are nice.

Jen So we're talking about step three, identifying your system requirements. What you're describing there is, if you're going to start offering premium support, are there tools and resources you need to add to your support team to enable them to do that? Am I getting that step right?

Miles Yeah. And for example, that Slack contact — standard support with 3,000 customers is probably not going to set up customer-specific Slack channels. I handle two accounts, I'm setting up customer-specific Slack channels, because that's all I do all day is talk to these two accounts, and they're special and they're paying for it. It's no problem usually getting them to open up those channels for me. But for the general case, no.

For example, with a previous company — my company grew by acquisition, and we acquired a company whose biggest customer had some stuff in their contract that we didn't previously provide. And it was basically a view of the bug database, which I'm normally religiously opposed to, but they got it. So we had to figure out how do we give them access to Jira without exposing everything to them.

That was a requirement that was given to me as part of this acquisition. Okay, let's figure this out. While I wouldn't recommend it as a general rule, it can be done. And it depends on your company, on your customers, on your culture.

I know there's one company out there I read about all the time on LinkedIn that exposes their case stats to the general public. How often you meet an SLA — you're not just telling customer X, or your customer base in general, you're exposing it to the public. Okay, that's cool, that's confidence, good for them. But it depends what level you want to expose to people.

Jen I'm thinking through system requirements, and really practically — if I'm a support manager and I've gotten buy-in from execs to do this, and this is part of a whole team push, practically what's a checklist of what I need to make sure will work?

You mentioned the CRM and making that work for the whole team so that folks can get that information in there. And also whatever help desk support is using needs to be configured to route those conversations to the right team.

Miles Right. The routing is going to be there, the flagging's got to be there. If you've got the features in your CRM system doing the SLA reporting and sending you notifications, so that you don't have to wait to violate an SLA before you get told.

That's partly why the redundancy of putting things in Slack from Salesforce was useful — if you're not refreshing your Salesforce screen every five minutes, you'll see it come in on Slack. And you can set up notification rules on Slack to send it to your phone. Okay, now if this thing comes in from that customer, my phone is dinging even if it's two in the morning. I know an after-hours case came in and I can decide whether I want to wake up and get involved right now because it's a P1.

For normal support delivery you're not going to go quite that far, but for that $10 million account you're going to want to be able to set up special things to make sure that they never worry.

Jen All right, so you're a support team manager, you've updated your system requirements, you're ready to launch this support. What's next?

Miles Next is what I would consider a trial launch. You want to find three to five customers from your step one for the proof of concept. Can we do this? Does it add value? What did we miss?

There are processes that probably you forgot to update. There are relationships and communication to sales and engineering that you may have forgotten to communicate. You want to make sure that you identify a couple of your engineers that are going to handle that daytime load. Or you're doing just the daytime load for that first trial — you probably don't want to go full-on 24/7. But if you're having problems during Pacific hours, here's what we're going to try and do for you. Let's see how this works and tune the program with you and for you.

Work closely with the account teams. You want those relationships, you want the role clarification — we talked about that, strategic versus break-fix, and where's the overlap.

You want to make sure there's an engagement process. If the CSM is on site and becomes aware of something, how do we want to engage support? Are we going to tell the CSM to tell the customer to log a case through the portal? That sounds actually kind of annoying for a customer that's that high-end. Is there another process? Can the CSM log the case on behalf of the customer, or do you want them communicating directly to support through a different means?

Jen I'm curious what that is. In your experience, what's the best way to handle that?

Miles I prefer that either the customer or the CSM put something in the case tracking tool. The case tracking tool is the single source of truth. If it's not logged, it didn't happen.

Jen Right, so no just DMing an engineer.

Miles Yeah. "We were down all last week, nothing worked." "When did you tell me?" "This morning." Then I can't help you until this morning.

I also do like to lobby for tools in the product itself that'll have a call-home feature if something bad is happening. So if the application, whatever you're selling, can create a case on its own saying "hey, performance is awful, open a case" — the thing about knowing beforehand is that if the customer then calls and says "performance is awful," you can say, "Yeah, we got notified from your system an hour ago, here's what's going on in our AWS, whatever." And that's being ahead of it. So I love it if the product can call home.

But again, until you notify support through the CRM, there's no record of this. How can I report on it? How can I fix it? How can I take care of this problem? So those tools are critical.

Jen That makes sense. I know I've used up a lot of your time here and I really appreciate it. I wish we could dig in further, but I want to wrap up with one really important thing that maybe sometimes we neglect, which is how do you measure your success? You've implemented this program — what are the data points that you're looking for to say, okay, this is good, we're going to go from trial launch to launch?

Miles There are a few things. Most of them are look-back numbers, I grant you. Customer satisfaction is a look-back number, but it helps. If you're doing anything like customer effort scores — which I've not done, but I respect customer effort scores — are they finding it easier to deal with you?

Just the direct feedback from the customers themselves, because when you're selling a premier service like this, customers are not shy about calling you to tell you what's working or not working. When I say, "I'm moving Sally off your account and moving Billy onto it" — "oh no, no, we love Sally, you can't take her away." Ah, I've got a data point on Sally. Okay, let's sit down with her. What are you doing that your peers aren't, that they love you so? Let's figure this out.

Retention, of course, is a big one. Whether or not the sales team is out there actively selling — do I have to sell sales on this so that they get me accounts, or do they see the value from those first couple of accounts saying "I want that for my account"?

Those couple of key accounts at my last job where we had even above and beyond my normal offering — that was because they had an issue and sales said, "Can Miles' team do this?" And, well, yeah, let's figure it out. Give me a month and I'm going to work with this other guy in support leadership and we're going to put together something. We put it together and it works so well for that account, two other accounts jumped on the bandwagon. If you have a success, word spreads.

But like I warn people with knowledge bases and customer portals — make sure you're ready when you go out with that trial. If you miss, it's hard getting a second shot at it. So think it through, get the processes, get what you think you're going to offer, do the surveys, get things in place.

Now granted, the first couple of trial customers, they're friendlies. They realize they're getting, in this case, usually something from nothing. So you're probably not going to burn the bridge too poorly. But internally you want to make sure you still have the support of sales and product and marketing — "no, didn't we try this last year?" "Yeah, but we want to do it again." "Well, what have you changed?"

So make sure you get as much of this right as you can. It's going to be wrong, it has to be dynamic. Every time I've run one of these programs, we've morphed it and grew it and changed it. It's a dynamic thing. Changing your account ratios, changing your pricing, changing the tools, adding a tool like Slack, adding a process like the assigned backups. This is a growing thing, you learn as you go along.

And even having done it all these years, if I get this job again, I'll learn more. That's what happens, you've got to grow with it. With AI, how can we leverage AI to make a premier offering even better? I'm sure there are people asking that question.

Jen That's great, and I appreciate you sharing all the learning you have done so far. I'd love to chat again sometime, maybe about another process.

All right, this is a huge issue, but thankfully Miles has broken it down into four steps for us.

First, confirm the market need. Make sure that you can identify your top revenue customers — and would they pay for more support? What do they value most? Talk to them.

Step two, choose your staffing model. Do you want to have a dedicated engineer per account, or designated? When you have a designated pool of employees you have more coverage but less intimacy with the customer. Keep that in mind.

Step three, make sure your systems are ready. Your help desk and your CRM will need to be able to flag premier accounts, route tickets to specific owners, handle after-hours coverage, and trigger proactive alerts to Slack or email or even to someone's phone.

Step four, launch a trial. Start with three to five high-value customers in a beta trial. Then you'll be able to prove value for this premier offering and use it as a proof of concept before scaling.

There you go — we've distilled that down into a high-impact four-step process to implement premier support. If you like this podcast's focus on tactical processes and you use Intercom, check out Supportman for instant AI quality review in Slack. We'll see you next time.

Under two minutes to live, no IT ticket required.

See pricing