Customer Support and Service Articles

In a support operation, time is everything.  Whether you are tracking how much time was spent on a client site for follow up invoicing or identifying trends against your various issues and defects.  Whatever the case, understanding and knowing the time consumption can help managers make key decisions that can improve the operation – and the product or service being offered.

If you could determine how much time the support staff spent supporting a particular product, what could you do with that data?  For starters, it may lead you to evaluate product stability.  Because the customer feedback typically enters your organization through the support department, the data collected by

that team will easily reveal stability issues for example (assuming your support tool allows you to track against each product).

This information can be shared with product managers, developers and those in QA.  Those teams can obtain an understanding as to why the same issue is being reported and also why your various teams are spending so much time dealing with a particular product issue.  Now they can identify it, attack it and fix it.  As a result, the contact volume on the support staff will be reduced and customer satisfaction will increase.

It may also lead to support staff needing more training on the product they are supporting.  It’s not uncommon for support agents to get tossed into the fire in some organizations!

How about time spent on your newer clients?  Are they calling to report the same or similar issue?  Are your support teams spending a great deal of time helping the customer make those final tweaks to their system after the commissioning is over?  If you could capture this data, it may reveal that not enough time is being allocated to the installation.  If this were the case, the data you can obtain from your support software could lead a field service manager to take a closer look at the installation timeframe and either adjust to capture more efficiencies or allocate more time onsite.

All of this (and more) is possible when you can collect time tracking data and share that information with various departments on your team – and that is really what I am getting at.  Sharing this data across departments to help each other perform their very best.

As part of our feature set in TeamSupport, each ticket and the individual actions (or entries) are time tracked, and not just against the ticket either.  You have the ability to track time against; Tickets, Customers, Products, Services, Individuals, or even a Group of people that perhaps represent a functional area of your operation.

- Eric Harrington

It seems our message of connecting support and development is making the rounds and finally getting some serious thought.  So much so, if you were to look close enough, you will see bug tracking solutions and help desk solutions are beginning to shift their marketing message.

This is a huge complement to TeamSupport and our quest to bring customer support and product development teams together – are the very reason we started TeamSupport.  Before now, there simply was not a solution that really understood this need.

It goes beyond saying that one system can connect these teams or use API’s and widgets.  There is a requirement to really understand WHY this is important.  In fact, most support agents and industry consultants already know this all too well.  If you have not had this discussion with your support teams, you should.  Better yet, engage your customers and listen to what they have to say.

The most straightforward example is the customer who contacts support about a bug or a feature request.  Support agents are typically not code writers – nor are they product managers.  So what is the support agent to do when this happens?  Well, based on their development teams using a separate solution, the answer is not much.

The support solution they are using will not know how to deal with a bug or a feature and certainly unable to tie the ticket to a specific product and version AND assign it to a developer or a product manager.  They can collect the information from the customer, but at that point, because the other teams are using a completely different product, the support agent has a few options.  They can send the other teams an email, go have face to face conversations – or hand deliver a physical note.

What happens next? Visibility is lost and the irritation and inefficiency begins – and usually in a major way.  The support agent has no way of knowing what the status is once it has left their department.  As a result, the support team cannot provide information to the customer when they call or email – and rest assured, they will call or email to inquire.

Internal finger pointing may result when the operation runs this way which makes things worse. Think this can be hidden from the customer?  Think again.  Attitudes can go sour and customers will know it by the verbal tone or even email exchanges.

Repercussions?  There are many actually, but the biggest threat is to revenue.  The customer will see their vendor as disorganized and out of touch.  Before too long, the vendor will develop a negative reputation.

Word of mouth can be the best or worst thing for a company.  Unless the company has cornered the market with their solutions, there are other options out there for customers to consider.

If this takes place, all is not lost, but the time and money needed to rebuild a reputation is unpredictable, expensive and all consuming.  Anyone interested in signing up for that?  I doubt it!

Most technology companies use separate systems to handle customer support and product development – or they waste an absorbent amount of time and money trying to develop their own solution or maintain an open source project.

So how do companies that provide customer and product support manage all this?  Simple.  Make each customer experience with support OUTSTANDING – EVERY TIME. Get your support and development teams on the same solution.

After all, today only lasts today so make it the best day.  Yesterday is gone and tomorrow is promised to no one.

- Eric Harrington

P.J. Jakovljevic’s recent article about TeamSupport and our quest to help technology companies break down the silos and promote a team approach to customer and product support.

P.J. is a TEC veteran and an APICS buff. He is an equal opportunity analyst (EOA)—one of the first to pay due attention to the little guys that tend to be overlooked by the big analyst houses. P.J. is a proponent of “separation of church and state” (both in society and in the analyst world) and is committed to writing equally “tough but fair” analyses about all vendors and solutions, whether they are TEC clients or not.

- Robert Johnson

Jerome Pineau, Sr. Solutions Consultant at XSPRADA explains how TeamSupport makes his job easier.

Click here to read his review.

Every company handles customer feature requests in different ways.  In the end however, there usually exists similar steps, regardless of your operation.  In some cases, you may find yourself wearing all of the hats and making all of these decisions.

1.  Customer requests a feature.

2.  Someone has to evaluate and say yes or no.

3.  If no, then someone needs to inform the client.

4.  If yes, then an ETA is determined as well as a handful of other things such as roadmap implications.

Of course there are many more steps involved but let’s stick to the basics for now.

As we can see from the simple steps above, we have implicated a handful of teams (or functional areas) within the organization.  Sales, Product Management and Development.  They all play an important role and all have specific contributions to make (even if you are wearing all of these hats).

TeamSupport makes this process very simple to deal with and keeps everyone in the loop.  How?  With TeamSupport, you have the ability to create custom fields as well as custom ticket status & workflow which gives you the freedom to be creative and define how you want this process to flow.

This allows you to not only involve the technical staff (Support and Development) with TeamSupport regarding your customers feature requests – but also allows sales and operational members to get involved.  As the status changes on a ticket, you can simply assign tickets to a specific individual or a group of people with a simple mouse click.

If you would like to learn more about how to maximize this process in TeamSupport, or if you would like to share your feature request process, add a comment to this blog entry or send us an email here.

I have worked with several companies that have very different views on this.  Most of them draw a line in the sand when it comes to giving customers access to the development team, and they simply refuse to let the customers near the developers.

I actually see both sides of this.  There are many reasons why not to, such as politics, communication, distraction, etc.  The developers’ main job is to write code,and many companies just don’t see the value in letting them do anything but write code in a relative vacuum.

On the other hand, customers feel involved and part of the process when they can actually speak with the developers of the product they paid money for.  Not only is it a great source of feedback forthe developer to hear firsthand what issues a customer may be having, but it is also an opportunity for customers to share ideas based on real world use cases.  There is no doubt that some of the best products I have been involved with have come from the developers having some sort of customer interaction.

How many software developers that write and support a group of applications actually know how their products are used at a customer site?  Based on my experience, I suppose it is fair to guess 50% of them, but I have no real data to back this up.  For the most part, the developers are focusing on the coding tasks they have been given and try to keep the versions and bugs under control.

I have always promoted conversation between developers and customers.  I also firmly believe in exposing the developers to various customer locations – even if for a day or two just so they can see how that particular customer is using their software.  A customer site beats the QA lab any day of the week in my opinion.

Of course this interaction must be managed as to not cause delays in actual codework, but the more a developer understands how their application is being used,the better the product will become and the happier your customers will be.

- Eric Harrington