I have done this type of support before very successfully.  The value we positioned was not that your named person was always available for you when you called, but rather they were very familiar with your account and configuration and would be able to manage and provide insight to the people who might do the normal phone support.  Simple questions or logging of issues would still be done through the hotline.  The call would get routed to the Named Support person, but that way it got logged properly and if they were out, someone else would pick it up.  The Named Support person would also do such things as track feature requests, provide status summaries to outstanding open issues, etc.  On the proactive side, the Named Support person would also update the client on upcoming releases - what specifically did the new features mean to them.  As well as we offered periodic product assessments to help them understand how and where they could use the product better. 

The number of accounts that a Named Resource could support was dependent upon the client.  I had one person who only managed one account - however, they were a strategic account, had multiple locations, and we were the bridge between all the different locations.  For others, it would average between 4-8 accounts.  It will depend on how many phone calls they were getting as well as the other activities on the account. 

Barbara Tygesen

My personal opinion is that to actually take this to a single resource is a recipe for disaster and disappointment - what if the person is
unavailable, leaves, gets promoted, etc.? What if two clients have “emergencies” at the same time? I have had some successes doing this
as a team approach - for a higher fee, the client is “guaranteed” to get a member of their assigned support team who knows the client and
its issues.

Darren,

I’m using one as a customer, and it’s far from satisfactory.  Either we have nothing for our rep or there are so many things it’s not possible for him to respond to them on a timely basis.  It’s hard to create a win/win due to availability and need.  We’ve tried single point of contact, who manages the support people behind the scenes.  This is a bit better, and you still run into access issues.

Rgds.

Mike

Hi Darren,

I’ve worked very effectively with named support engineers, taken from a resource pool in the past. Generally, customers are prepared to pay a premium for such a service (I historically charged an additional 35% for this service).

How many accounts each engineer can handle will certainly depend on how long a typical support call takes, plus the complexity of each named customer environment. Unless your products/services are very straightforward, I would suggest that 7 +/- 2 makes a sensible maximum number.

A real winner for customers is sending the named engineer on site (say one or two days a quarter) to deal with non-urgent issues. This is a real value add for customers and definitely worth the investment of time.

Depending on the size of your resource pool, you may wish to consider allocating a primary contact, plus a secondary contact, to cover periods of unavailability, whether caused by holiday, sickness, training or merely excessive current workload for the primary.

Most customers who subscribed to this service were happy to wait for a call back, because of the time saved through dealing with an engineer who knew about their specific implementation. Certainly offering the secondary option helps ensure that you can still meet whatever SLAs, or service level targets you may have in place. If you go for the primary/secondary approach, you should ensure that the named engineers can share account and implementation knowledge effectively.

For very large support organisations, a tertiary option defaulting to the regular service desk may make sense, in the event that both the primary and secondary are unavailable and your SLAs are starting to look threatened.

I would also suggest that you consider implementing a Technical Account Management function for those of your customers large enough/strategic enough to be interested in retaining a named support engineer. This gives you a familiar person for escalation purposes, regular progress meetings and the opportunity to become a customer advocate/trusted advisor, which builds your credibility with the customer as well as closing the loop with your sales force, to make them aware of potential new business opportunities.

Best Regards,

John

I have also experienced that this type of program can be very successful. Customers needed to be on a higher support
level, then paid around $40k to $50k for this program. Reps typically handled around 6 customers. Initial calls would be
taken by the phone team, then the case would be taken either by the named individual or a named backup.

Margaret

Wow, we actually do our business this way but never leveraged more revenue out of it or didn’t even market our
operation this way to get more sales. Thanks for the idea (someone may say it is old but it is new angle for me at
least).

Here is how it works. We take a client and define IT/business services that we are supporting. IT is very
important that our support guys don’t think of a client as 30 servers, but rather as email/blackberry services, CRM

Wow, we actually do our business this way but never leveraged more revenue out of it or didn’t even market our operation this way to get more sales. Thanks for the idea (someone may say it is old but it is new angle for me at least).

Here is how it works. We take a client and define IT/business services that we are supporting. IT is very important that our support guys don’t think of a client as 30 servers, but rather as email/blackberry services, CRM system, financial application, inventory, sales database etc.  Then a client gets 2-3 guys as a support team (we are maintaining relatively large infrastructures). All our guys are very “wide” in knowledge, maybe not too “deep” but definitely have a big specter of IT issues that each one can cover. Each one of them specialize on one thing, network, servers, storage etc. So when a client calls he gets one of them. If it is an urgent issue the client would not want a specific person. He would want the service to be restored to normal operation and doesn’t really care who is going to be doing that, he needs it up and right now. In the most cases we know about a failure before we receive a call and either calling the client about the issue or have some preliminary information about it. 

If this is a reconfiguration issue then it is a different story. The client usually wants a “specialist” in this field. If the “specialist” is busy, the client is OK to wait but to have the level of knowledge and the “feeling” of that specialist that the client wants. Certainly there are clients that we cannot create this type of intimacy but in the most cases it works. Sometimes we also do “cross-team” resource sharing when we need a strong engineer to help another dedicated team. We also give our techs full freedom to request help from other teams of switch client support cases unless the client is satisfied. Another key point that client can easy escalate it to a higher manager so the manager can correct the flow. Little by little clients know their team members and know who they want to work with and if they are willing to wait if the issue is not urgent. So we have no problem if our tech is saying: “Bob, I am taking that database backup for Jack’s team, so when I am done I will call you right away”. But it has to be only within a single client.

Once we had a call from our client like this: “I want this guy out of the team”. Well, we re-shovel the team.

So I am big supporter of flexible support organization versus anonymous support techs. It builds intimacy in technology. If techs are good personally and technically (we should not keep bad people), clients even willing to forgive small mistakes and often protect techs in front of management (us).

As for number of clients, one strong team of 3 people can easily support 200-300 devices. In our case it is servers or storage or network equipment.

Thanks again for a good marketing idea. We are an excellent IT group but very small in marketing. So it is great help.

As the matter of fact I am a new member but already got at least 3 good ideas that we want to implement.

Thanks all.

Mike P.

I’ve run into 2 main situations in approaching named resource support.
1) Support of in-house hosted applications built on specific company product technology. The product company then offers Technical Account management as a premium support package (among other support offerings) focused on the client account in general where the company technology plays.  In this case, as stated earlier by Barbara, it’s usually a strategic account that has mission critical systems.  Typically each resource would handle 2-3 accounts - so you can imagine the price point is high to the customer but relative to the system costs and operations risk it’s a value add to the client.

2) Support of ASP hosted applications, something my company does today for OpenAir, which commands a lower price point since these are usually subscription based models.  It’s not really a named resource they are paying for but a focused team that knows the business model of the client using the application.  What ends up happening is that one person tends to respond to the customer repeatedly which ends up instilling a ‘named resource’ feel but a general help desk account structure is used so everyone is informed about the client (so there are plenty of backups available).  Overall it reduces the price to the client.  In this case, I’ve priced support of accounts around 6-8 per person depending on client size, complexity, overall responsibility of outsourced support (SLA), etc. 

Thanks

Mike,

My experience has been similar to yours. The only way we resolved it was to have ‘in house’ projects that did not have time constraints assigned to
these resources to work on in their slack time. These included methodology, training, best practices, etc.

Joe G.