Metrics for Technical Account Managers (TAMs)
Many thanks to Ravi Desai for suggesting this topic.
Many support organizations offer the services of a Technical Account Manager (TAM) or Service Account Manager (SAM) to larger accounts, either as a fee-based option or as a complimentary service for customers that meet certain criteria, typically large annual fees. The scope of the account management service can vary, from glorified escalation management (not what I would recommend, certainly not for a fee-based option) to comprehensive proactive support including regular health checks, custom recommendations for using the product, and exposure to the marketing roadmap. Not a few programs also hope to sell more products to customers with a TAM, based on a better knowledge of the account. All that to say that the metrics for a service that can be so multiform are necessarily varied as well.
1. Is it selling?
If you sell the service, an obvious metric is whether customers are choosing to purchase it and especially renew it. Not that account management will necessarily sell widely: it is usually designed for the top 10% of accounts so the selling targets need to be adjusted accordingly. On the renewal side, however, you should see a much better performance than for regular support contracts. Non-renewal events outside of large changes such as acquisitions should be questioned.
2. Is it working (for the customer)?
The whole point of account management is to help the customer be more successful so an obvious success metric is that the customer is satisfied with the service. An annual formal survey would fit the bill and allow measuring the TAMs as well as the service overall.
3. Is it working (for the company)?
The TAM’s performance also lies with internal issues: communicating appropraitely with the various resources within the company and managing to be the customer’s advocate without forgetting that their loyalty needs to lie with the company. For that, I would suggest a 360 evaluation from the various parties with whom the TAM interacts: other support responses, Engineering, Marketing, and Sales.
I would not rely too much on additional revenue opportunities with the account. It’s true that TAMs can be very helpful in ferreting out opportunities but I find that if they are compensated on sales it changes the relationship with the customer and erodes the trust of the customer in the impartiality of the TAM. Better to rely on an evaluation from the account team (which will, necessarily, include a judgment on whether the TAM is able to find and report opportunities for follow-on sales).
I would also not rely too much on mechanical measurements of how many customer meetings are held, for instance. A TAM could hold lots of meetings where nothing is accomplished and the customer relationship would be no better. By all means use such mechanical metrics day-to-day, but when performance review time arrives rely on customer satisfaction reviews and 360 reviews since they will speak about effectiveness, not just efficiency.
What metrics do you use for your TAMs?
Great topic! There are a couple of things I like to measure TAMs on – one is the support backlog. I would expect a TAM to be pushing (cross-functionally if necessary) for resolution of their customer’s issues and keeping a high level of visibility on them. If a TAM is newly appointed to an account, I would expect the backlog to trend down. If they have been on the account for a while, I would expect the backlog to stay below an agreed on threshold.
Another metric is project success. If a TAM is at all involved in product installation, upgrade, patch, etc., I would track the success rate of those projects. A TAM should be the customer’s advocate internally to make sure a patch was thoroughly tested against the reported bug before installing, for example, and that the people executing the steps are trained, and that project timelines are vetted (don’t tell the customer it will require 30 minutes of downtime to upgrade and then it takes 2 hours). Sadly, I’ve seen these types of projects fail for many reasons that should have been caught internally before the product ever went to the customer, and the TAM is a good backstop to reduce this type of failure by asking the right questions and holding internal teams accountable for their answers. I think this is best as a team metric to drive the proper rigorous internal processes into place (which can take a while), but it can be used as an individual metric if one individual’s performance deviates from the team norm significantly.
Love your ideas, Jennifer. I can see how the TAMs can team up with the support managers to keep backlog in check.