In the context of test equipment, support contracts ultimately accomplish three things:
Save money if things go wrong
Save time when help is needed
Make money by increasing efficiency
Despite the above, many people question the value of these contracts. Since most people only consider support when things go wrong, let’s start there.
insurance | ɪnˈʃʊər(ə)ns |
a thing providing protection against a possible eventuality.
According to the National Safety Council, a person has a one in 103 chance of dying in an automobile accident. To put that in perspective, the same report indicated that Americans have a one in six chance of succumbing to heart disease, and a one in seven chance that cancer will be the fatal factor in the end.
The point of this (admittedly morbid) comparison is that the average American still spends over $1,400 per year in car insurance. It’s almost equally likely that you’ll die from falling down.
So why do we spend so much money on something that isn’t that likely to happen?
Truthfully, in most developed jurisdictions the law requires us to carry car insurance. These legislators realized that despite the relatively low probability, the potential cost of such an outcome will be far more than the vast majority of people can afford. Hence, car insurance provides protection if you happen to be the unlucky one in 103.
Support Contract ≈ Insurance
Unfortunately, I don’t have statistics representing the likelihood of a catastrophic test equipment failure. However, I can give you some simple examples of situations that might lead to unscheduled downtime:
Repair due to improper or lack of maintenance
Repair due to improper use by operator
Repair (and possible re-calibration) due to damage from failure (or other catastrophic event) of the component-under-test
Reprogramming due to user errors in measurement and/or control scripts
Repair due to excess wear from out-of-spec fixture/shaft designs (i.e. excess runout)
Repair due to excess wear from thermal cycling
Unexpected component failure of the test equipment
And so on…
Unscheduled downtime usually results in costly repairs, inefficient use of resources and lost revenue.
There are ways to prevent some of the above examples from occurring and lessen the impact of others that cannot be prevented. While we work hard to design systems to mitigate the possibility of each of these scenarios, we cannot prevent unscheduled downtime entirely.
A backup camera won’t stop you from hitting a pole (or a small child) if you’re not paying attention to the screen. Considering how distracted we are these days, this example isn’t far fetched. Car insurance at $1,400 to protect you from a $1 million lawsuit suddenly doesn’t look so bad.
Hence why support contracts exist. Part of the purpose of these contracts is to provide insurance against unscheduled downtime. Having effective support will identify many of the root causes that lead to unscheduled downtime (through preventative maintenance) and significantly reduce the amount of time it takes to solve an issue when it arises.
Support Contract = Savings
Speaking of savings, it seems counter-intuitive to think that spending money saves money. If the risk of unscheduled downtime is low, having a support contract as an insurance policy may seem less appealing. Especially when you buy reliable test systems, like ours.
Unlike insurance though, support contracts provide help whenever you need it, not just when things go wrong. This help saves time—and we know that time = money, cliché as it is.
The cost of a test engineer
But how much money? Let’s do an exercise by considering the cost of the average Test Engineer.
Average salary for test engineer: $75,000
Average working hours a year: 2,000 hours
Effective hourly rate: $37.50 / hour
Beyond wages, the support required for this engineer to be successful also has a cost. This includes obvious things, like employee benefits. It also includes the cost of managers’ time, HR, equipment/supplies and other overhead burdens that are needed to enable this employee to carry out his/her duties. Keep in mind, these costs are incurred whether the test engineer is doing his/her scheduled work or not.
A common estimate is that this burden is somewhere between 150% and 200% of a person’s salary. Considering the amount of equipment and resources involved with product validation and the value of time required by engineering and program management oversight, we will use the 200% rule.
Overhead and Opportunity Cost: 200% x $37.50 = $75 / hour
Fully-loaded labor cost: $37.50 + $75 = $112.50 / hour
The cost of supporting test equipment
ATA makes test equipment, so we can easily analyze historical data of support cases involving our systems. These cases include support for unexpected software/hardware issues, training, maintenance and engineering assistance. Let’s look at some trends:
Average support case (time to resolution): 4 hours
Average cases per year: 10 cases per system
Average hours spent by ATA: 4 hours x 10 cases = 40 hours
Based on this data, we often sell 40 hours of ATA Assist™ upfront for $6,000. As cases come up and we render support, the balance of 40 hours is reduced by the time we spend.
The alternative is for the test engineer to tackle the cases themselves. We encourage test engineers to be self-sufficient, but the reality is that we can often solve cases in half the time (more on that below).
Based on these assumptions, the average cost to solve 10 cases annually:
4 hour case / 50% efficiency = 8 hours to solve
8 hours x 10 cases = 80 hours
80 hours x $112.50 = $9,000
Remember, the $112.50 rate includes the opportunity cost of this test engineer solving test equipment cases, rather than running tests and providing valuable insights from results.
Savings by support contract: $9,000 - $6,000 = $3,000
By the seventh support case, the contract has more than paid for itself. Across multiple systems and years of use, the savings can become quite significant.
Support Contract = Increased Efficiency
You might be wondering how I came up with the 50% efficiency figure in the above exercise.
A test engineer’s job is to define, set up, execute tests and analyze the results. They are successful when they create good tests—ones that capture failure modes that could appear when a component is in the field. They are the experts at interpreting data, assessing risk and providing insights to the development team. They show their value when they save your company from warranty claims, recalls, or worse.
Their job is not to figure out how to program a machine. It isn’t to remember to change a filter. It certainly isn’t to spend weeks calibrating sensors to very precise standards.
We can support our machines in half the time, because we design the systems and are the most knowledgeable on how they work. We focus on being the experts of test systems, delivering the training, support and maintenance to make the test engineer more efficient in their job.
Do you really want a test engineer spending twice the amount of time supporting equipment, when they could be using that time to produce valuable insights from test results?
Do you want to apply expensive overhead burden against activities that don’t add value to the products you are developing?
Do you want to waste administrative resources rushing to process POs and invoices in the event the test engineer needs help anyway?
If you answered “no” to any of the above questions, you should get a support contract.
The time saved by a support contract can be utilized to run more tests, increasing product validation throughput. Increasing throughput means bringing products to market faster, capitalizing on more market opportunities and increasing returns.
Alternatively, the time saved can allow for more elaborate tests, potentially capturing previously uncovered failure modes and preventing costly warranty claims.
In either case, the result is a positive impact to the bottom line. That’s more than I say about my car insurance.