Easier Service Through Color Coding

By Larry Laux
President and Founder

I’ve been around the service industry a long time, over 25 years. I have been able to see hundreds of service operations, servicing a wide, wide variety of products - blood analyzers, medical imaging equipment, overhead doors, coin counting machines, silicon wafer producing machines, copiers and many others.

I am amazed and impressed at the amount of user-service that is in place today vs. even ten years ago. Hewlett-Packard was an early winner on this front, putting much of the print mechanism in the toner cartridge and having users ‘do it themselves’. It really surprises me how willing consumers are to open their PCs and put in a new disk drive.

So here’s my question.

Why don’t manufacturers color code their components?

In some industries there is a strong trend in product design to introduce modularity, or easily swapped component structure, into the device. This is so the service person (or the users themselves) can relatively easily swap out a bad part, insert a new one and be back up and running.

So, if there are five major components inside an imaging machine, why not make one tan, one blue, one orange . . . you get the idea. I think a company could REALLY advance on the user self-service front. Or if self-service is not on the table, technicians could be revenue producing sooner and with less training.

Have you ever seen a product with color-coded components?

Attacking Service Problems - The Fun Way

By Larry Laux
President and Founder

Some of the problems in service are profound, some are trivial.

Some can be attacked in a fun way.

Several years ago, a Metrix client that services hospital and lab equipment was looking for a way to grow revenues. Their U.S. Director of service came up with a clever idea that worked well and I’ll share it with you.

They had a good business book in both service contracts and in break/fix. As usual, margins were better on the contracts side. Other than waiting for sales to sell more new products, how could they expand their revenue opportunity in contracts?

The national director of service rolled out a program to the service engineers. "Find a device" he called it. Whenever an engineer went on site for a call, they were to ask and look for other devices that they could service, but that weren’t in their installed base (they could refer to their laptops to see the known installed base at the site). They would then report back models (in some cases serial IDs) and they received ‘credit points’ based on certain brands, models etc. The manager had pre-set values for different types of products, higher value for some, not so much for others.

At the end of each month, point totals were published, and after the program wound up (4 months as I remember), points could be exchanged for marketing stuff (caps, shirts, jackets) with the company logo.

It actually turned into a competition of sorts for some of the field folks, to see who could claim bragging rights.

As a result a wide pool of new service contract prospects were developed. Of course, they were all pre-qualified as each site was already an existing client. They just needed to market to them to add these other products to a service agreement.

It worked well for them. Maybe your company can use a similar program.

Have fun!

The Discipline of Project Justification

A multi-part series
By Tom DeVroy
VP of Sales

As Metrix launches this blog, I’ve been asked to contribute on topics that might be relevant to our target markets and customer installed base.

As VP-Sales I see a lot of prospects and customers make an effort to quantify the tangible business benefit of a service systems project. For that matter any significant project that impacts their business. This might include field automation, back office processing, integration, new field devices, communications, new service initiatives, etc. Often times the person who is the project lead does all of the homework, might establish good vendor relations, go through a thorough evaluation, and fall short of selling the final vision to management. Several variables, of equal weight need to be considered, in ‘selling’ a project to management.

Most management is interested in what impact the project is going to have on the business. What resources are involved, how long will it take, what risks do I face, and what can I expect at the conclusion of a successful project. How is this project going to either make me money, or save me costs.

This multi-part series will comment on some of these considerations. I’d like to organize the series as follows:

- Define the problem and build the hypothesis
- Establish the business case
- Articulate the solution
- Define the risks and assumption
- Establish the resource requirements and timeline
- Define the change management implications
- Build a narrative
- Separate hard and soft savings
- Pick a modeling tool
- Build a realistic financial model
- Define the tracking and reporting mechanisms

I’d really like these posts to focus on how a project lead sells a project to management. Even if management intuitively knows they have a problem, or that a better mousetrap can be designed, they need to have some confidence that what they are investing in will return some level of expectation. For instance, when you buy a new car you might go through the same kind of analysis. I like to use cars and houses as samples of buying patterns.

When you go to buy a car you usually will run through the following mental machinations. Do I really need this? For what? When? How much can I afford? What image will my car reflect on my family? These simple questions start to drive solutions - car types, models, and makes. But this is a long way from actually signing a deal with the sales guy.

In the next post I’m going to pose the question of building the hypothesis. If you have ideas or suggestions please share them with me.

View Part 2 Here
View Part 3 Here
View Part 4 Here
View Part 5 Here

Unique Links in your Service Chain

By Larry Laux
President and Founder

Having been in the business of providing software for service organizations for 25 years, I would say that all service organizations overlap business process for 50% to 70% of their activities.
When the product doesn't work, someone needs to do something: go there & fix it, or send the product back, or send a part for the user to fix it, etc. Doesn't matter if the product is a medical imaging device, a gaming machine, a piece of computer equipment or a door. And at the simplest level, who went, what did they do, can we send a bill or collect money are the building blocks of a service process. Such are the links in the Service Chain that most service organizations would easily recognize.

And what about the balance of activities, the 30% to 50% that does not overlap?

Those activities are the links in the Service Chain that are the unique bits of a service operation. Sometimes they arise from the particular properties of the equipment being serviced. An example would be gear containing radioactive materials, which require special tracking and handling. Government regulations (think medical devices) require certain process steps not needed in refrigeration repairs. The customers may be the cause of specialized service chain process (again, government as an example requiring special security clearance for access).

Even if you see the product you are servicing as a commodity, the unique bits might be how you differentiate your service from the competition. This 'special sauce' makes your service chain unique and, we expect, more valuable.

So here are a few questions to ponder regarding your service chain:

Do you understand the basic links in your service chain that are the same or very similar to your competition?

Can you identify at least two unique links or processes that are a) repeated frequently enough to be significant and b) are an opportunity to make money?

Are you making money on those processes?

Welcome to the Metrix Blog!

By Larry Laux
President and Founder

Hello and welcome to our new blog. In both my personal and professional life, I’m an avid reader of blogs. However, as I searched around the blogsphere I had trouble finding a blog that talked specifically to the service management industry. This is why we decided to start the Metrix blog.

This blog will be a "team blog", meaning I’ll be posting here along with a team of other bloggers from the Metrix staff. In the future, we are considering bringing in guest bloggers from partners, industry analysts and other service industry experts. The blog will be updated at least weekly and at times more often.

I hope you enjoy the blog and encourage you to stop back often and make comments on our posts.