Supporting New Software? No Problem.

One of the first stages of the software development life cycle is the roll-out of brand new software and with it comes that awkward honeymoon phase – it’s anyone’s guess as to what problems might arise during the first few weeks of use. With this comes a sense of uncertainty, but it doesn’t have to be all that scary! Since I’ve started working at Algonquin Studios, I’ve seen many old and grizzled systems scrapped in favor of bright and shiny new ones and I’ve learned a lot about piecing together a support process for when you aren’t totally familiar with the new software. Here are a few important things to keep in mind when venturing into uncharted territory:

There will be bugs. Probably more of them than you expected.

Even if you have the most fantastic software developers imaginable (like we do here at Algonquin), there are going to be unforeseen issues that pop up, so expect a sizable workload increase in the first couple months after releasing a brand new system. This leads to my next point…

Stay organized and consistent with bug tracking.

With an increase in bug reporting, it’s vital that the support team is clearly documenting all bugs reported and all team members tasked speaking with end users are kept up-to date on issues as they develop. Being diligent about your tracking will ensure that when it comes time to fixing those nasty bugs, everyone has as smooth a ride as possible.

Make sure you manage customer expectations.

As with all customer support issues, it’s important to manage expectations about bug fixes and requests for new features (Hey, I actually wrote a whole post about that here!). If there’s an issue or request that a user is anxious about seeing to resolution, let them know that you’ll be documenting the issue to be reviewed, but make no promise of when it will be completed. Not everything can be fixed or added at the same time and it’s best not to give false expectations.

Create and update a Knowledge Base from the get-go.

If you’re not keeping an updated Knowledge Base for your support team, you need to start… And you need to start yesterday. A centralized location for in-house use is crucial to being able to provide consistent answers on issues as they arise. Are you receiving the same questions on how to do a specific task in your software? Create a step-by-step “how-to” that you can send to customers quickly and easily, saving everyone a whole lot of time and confusion.

Have a simple way to escalate issues on a regular basis.

Whether it’s a weekly meeting or a regularly-sent report, there needs to be a way to let upper-level management know what’s going on. It’s ultimately not up to the front-line team to decide what gets fixed and when, but it is their responsibility to make sure the higher-ups are able to hear about the most dire issues. If there’s no process in place to communicate this, make sure you create one so the development life cycle can progress naturally.

Remember, as bleak as handling support may seem at the launch of new software, it will always get easier as time goes on. Implementing a brand new system is a learning process for both end users and support teams, so treat it as such! Look at it as an opportunity to grow your own skills and knowledge and reassure everyone involved that the process will all be worth it in the end. Every company will handle the launch of new software differently; what are some examples of procedures that your team utilizes when implementing a new system? Leave a comment and let us know!

Advertisements

Problems Don’t Float

Software developers have access to helpful debugging tools that let us step through the logic of our code and discover lines of code that might be misbehaving or causing problems. If our code is generating an error, the debugger will tell us which line of code is at fault. If we know our data, we know what results to expect and we can work through the code to diagnose problems if we don’t get the expected results.

Diagnosing problems during software development is relatively easy. The real challenge comes when your software is in operation and the end user has an issue–users report the effects of a problem and we, as developers, have to diagnose the root of the problem from the user’s description.

In the health care industry, they often remind doctors to cure the disease, not the symptoms. The same should apply to software developers; it’s very easy to get mislead by symptoms. My favorite “explanation” from an end user is “It worked before and now it’s not working.” This vague statement always sends developers down a path of investigating what changed between when the software worked and when it didn’t. Often, this investigation turns out to be a waste of time.

Let me give you some real life examples of being led down the wrong path thanks to the wrong focus:

My friend, a staff engineer for Delphi, had to diagnose a problem with overheating vehicles. The company’s customer service staff analyzed all the issues reported and came to the conclusion that most of the cars reporting the overheating problem were yellow in color. The engineering department was misled down the path of studying whether paint color had an effect on the temperature of a vehicle’s engine. Later, they discovered that the overheating was caused when the vehicle’s engines idled for too many hours during the day. Many of the cars that reported the problem were cabs in New York City. Since most of the cabs spend a fair amount of time idling while waiting for passengers and most NYC cabs are yellow, the customer service team’s analysis of the situation was accurate (many cars with overheating issues were the same color) but it didn’t get to the root of the problem (idling time).

I once wrote an application for processing reversal of payment transactions. After the application was in use for a while I received complaints that it didn’t work when processing reversals that resulted from bounced checks. I knew I’d tested for this scenario, so I was upset to learn that something was going wrong in its “real life” use. I found out later that a new staff member had been assigned to process the bounced check reversals. This new employee wasn’t properly trained and was mistakenly entering check numbers in the account number column, and vice versa. The problem wasn’t with bounced checks; it was user error. But I wasted a lot of time researching the bounced check stuff before we discovered the real issue.

This leads me to a line one of my Operational Analysis professors used to use: “Problems don’t float, only their effects come to the surface.” Don’t get misled by how a problem is described to you, instead do your own investigation; build your own understanding. Don’t just skim the surface; you have to dive deep if you want to find the root cause of a problem.

Here are few basic steps I’ve always found helpful when diving deep:

1. Collect examples of where the application malfunctioned and make sure you don’t limit the examples based on how the problem was defined to you. Do some analysis of your own to see which data sets produced the wrong results.

2. Compare the data to the source document to eliminate any data entry issues. Don’t assume anything. I remember one application where data fields were mislabeled during a configuration step, causing the wrong data to appear in the wrong columns.

3. Make sure that business requirements haven’t changed. Try not to offend the user reporting the problem, but make sure the output they expected matches the business requirements you followed to build the application. I remember an instance where a payroll auditor held back hundreds of paychecks, declaring that salary calculations were wrong. Many hours were wasted verifying the software used to process the calculations, only to discover that the payroll auditor hadn’t been informed that pay raises had gone into effect.

4. Work through the application using the data from the examples you collected. Make sure each step of the way that the output matches the business requirements. Again don’t assume anything, work through each and every step. Not only will this help you diagnose the problem reported, you might discover some other malfunction that was overlooked during development time.

And finally, remember that once you do uncover the root of the problem, you congratulate the end user for discovering that special “hidden feature” in your application!

Encouraging Great Customer Support

Just last night I had to call the support line for a service I recently cancelled but still had a few questions about. The call was frustrating and I didn’t get all the answers I needed before I finally gave up and ended the call, dissatisfied and unlikely to ever work with the company in question again. While the call was painful, the experience got me thinking about the support we here at Algonquin Studios offer and take pride in. As a Support Representative, I genuinely strive to be helpful to our clients and hope that their experiences with us are good ones.

My colleagues and I have written blog posts in the past about how to make your support experience the best it can be and how to ensure you get the most out of the time spent on the phone with us. This week, I wanted to switch things up a bit, though, and share some ways we can all encourage the customer service people we talk to on a daily basis, helping them continue to do a good job for us:

Smile
Support reps can tell when you’re smiling, even through the phone lines. We know you’re likely calling because something is wrong or you’re experiencing some sort of difficulty but smiling helps your voice to sound friendly, warm, and open-minded and puts both of us in a better frame of mind to tackle the issue head-on.

Give Us Details
If you’re calling about an error message you received when using our software, take note of what the actual error message says. The fact that you’ve done a little work on your own, prior to calling us, can make us feel like we’re in this together and that solving your problem is a team effort. Plus, extra effort on the front end will save us both time, help us get to the root of your problem (and it’s solution) more easily, and get you off the phone and back to your real life more quickly.

Don’t Be Afraid To Joke Around
Humor is one of our “Four H’s” here at Algonquin, so we’re definitely not afraid of cracking a joke or two, even at our own expense! In reality, most of us love jokes as much as the next guy and humor can be a great way to de-stress a situation, so my coworkers and I love talking to clients who know that, even in the face of a problem, they can make the best of the situation and crack a joke. It’s another great way to foster a team spirit and show that we’re all in this problem-solving experience together!

Say “Thank You”
Yes, they’re just two little words, but believe me, those two words are powerful! Never underestimate the power of “thank you,” even in the face of a difficult situation or issue that requires additional follow-up. It makes me smile when a client says “thank you” and helps me feel like I’m truly appreciated for the job I’m doing.

So, those are some of the ways our clients can help me feel better about my job. What insights do you wish you could share with people that could make you much happier in your work life?

Don’t Hang Up Yet! Things to Remember When You Call Tech Support

I receive phone calls from first time tech support users everyday. Some of these callers are quickly able to hone in on the right questions to ask to get the answers they want, but others don’t say much beyond “um.” We want you to get the most out of the time that you spend with us on the phone so that you can get the most out of your software and because, hey – time is valuable to all of us! So keep these things in mind when you call and you can be sure a resolution isn’t too far away:

Bugs

If you called in about a bug in the software you’re using, ask if there’s a known work around you can use until the bug can be corrected. If it’s a newly discovered bug, we might not have a work around yet, but ask for a follow up in a few days because as we work through the specifics of the bug, we might just discover one!

Errors

If you called because you received an error message, you’ll want to make sure we talk about how to prevent the error from happening in the future. While some errors aren’t caused by the user directly, there are some that happen because users make a mistake somewhere along the lines or try to interact with the software in an odd or unsupported way. These types of errors can be easily prevented and knowing how to avoid them in the future can ultimately save you time (and frustration!).

Feature Requests

If you called us to ask about a feature that you’d like seen added to the software, remember to ask your support representative when they might have additional information on the feature’s possible development. Of course, release and development schedules may sometimes mean a specific timeline is hard to come by, but following up in 2 – 4 weeks to see if there is any additional information is always a good idea and can help keep your request top of mind for our support reps and developers.

Miscellaneous

No matter what the reason you called, if we are unable to give you an answer right away you should always ask when to expect a followup phone call or email. No matter how good a support team we are, we won’t always have all the answers and we may have to consult with our teammates in order to reach a solution or resolution for you. Sometimes our research will take an hour but sometimes, in order to get into all the details, it can take much longer.  Make sure you provide us with a way to contact you once we have all the necessary information and remember to ask for a “ballpark” date and time when you can expect to hear back from us.

Our main goal is always to ensure our customers have a positive experience when interacting with our software and communicating with us. In your job, what are the things that you wish people would remember to ask or do when they call you for help?

Getting the Most Out of Your Software

As we all progress further into the wonderful world of technology, more and more of our daily tasks are gravitating towards automation.  Whether it’s cars that can parallel park themselves (and much better than I could hope to, might I add) or garage doors that can be closed from another continent, technology can make our lives easier in seemingly endless ways and, to me, it seems counterintuitive for businesses, big or small, to resist the inevitable shift towards the technology-friendly way of the future.

Several of the software packages I support are geared towards helping companies in the service industry garner additional business opportunities and make existing business practices more efficient.  From my perspective as a software support representative, the companies having the most success are the ones who squeeze all the benefit they can from all of their software.

During my time working with companies in the service industry, I’ve learned that so much of what you get out of your software depends entirely on the effort you put into it and so, I present you with my personal list of things you should be doing to get the maximum bang for your buck. After all, if you’re shelling out good money for software licenses each month, don’t you want it to work as well for you as it possibly can?

  • DO take advantage of available training sessions.  SWRemote, for example, offers an open training session each week, completely free of charge. QuantumCMS offers free user groups, tutorials, and a community forum to all clients, as well. Not only does the training benefit new users, but it can also help users who have previous experience with the software by highlighting new tricks, tools, or shortcuts they may not know about.
  • DO keep an open mind when learning new software.  It’s easy to get frustrated and take an “the old way was better” approach but it’s important to judge if the old way was really the most efficient using facts, not just an emotional, “gut” response, and to understand that the benefits of a new systems can often far outweigh any learning curve that may exist.  On the other hand, staying open-minded will also help you gauge the true usefulness of the new software once you’ve become accustomed to it.
  • DO utilize your support team.  If frustrating issues arise during your use of your new software, you can be assured that the support team would like to hear about them. And don’t be afraid to ask for help if you need it. I’ve received comments along the lines of, “I feel bad bothering you with this issue” but that’s exactly what I’m here for – helping users is the sole reason my position exists!
  • DO discuss the use of the product with other users (colleagues or others in your industry).  They’re the ones putting the product to the test in real-world situations so they might be able to offer helpful advice or tips that can help your business thrive.
  • DO make feature requests or offer improvement suggestions on a regular basis.  Making a request is one of the only ways to ensure your software development team knows there’s a feature you’d like to see; for the software that I support, the vast majority of enhancement ideas come directly from our most vocal customers.  If there are changes you’d like to see, speak up!

The obvious goal of most technology is to make things easier. If a specific piece of software isn’t working for you, it’s in your best interests to figure out why but keep in mind that “easier” doesn’t always mean that you won’t have to make an effort to learn or change. Remember this and you’ll be sure to stay ahead of the curve and get more value from the things in your life that are designed to help!

White Water and Software Support

The view from my weekend office - Lower Falls, Genesee River, Letchworth State Park

Some people may not know this but I have two jobs.  My full time job here at Algonquin Studios, as a Software Support Representative, and my part time job, as a weekend warrior guiding rafts on local white water rivers.

At first, you may think these jobs are completely different from one another.  At one I’m in an office, sitting at a desk and computer with Wi-Fi easily accessible; at the other I’m outside, sitting in an inflatable rubber raft that I could easily pop with the knife I carry, without the ability to make a phone call (even if I carried my cell phone with me).  But in reality the jobs are quite similar; it is my responsibility to make customers happy and ensure they have a good user experience.

Here at Algonquin Studios, my goal is that our clients will be smiling when they hang up the phone with me.  People call in with a problem – the problem can be as small as not knowing how to print an invoice or a bigger issue that takes my team a few days of research, to figure out exactly what happened, before we’re able to get back to customer. Whether it takes me 5 minutes to resolve the issue, or 5 days, my ultimate goal is the same – helping the client and providing quality service.

When rafting, my ultimate goal is no different – to give the guests in my boat a fun, safe trip down the river and have them smiling when we get to the “take out.”  Whether it’s 35 degree day, with snow falling, or an 85 degree day, with the sun shinning, I’m doing everything in my power to give my guests the best user experience I can.

At both jobs, I’ve got a team of individuals backing me up to help accomplish our common goal.  We work together asking and answering questions, learning from each other, and helping each other out so we we’re always getting better at what we do.  And, at Algonquin, there’s never an answer of “sorry, we don’t know the answer” or “sorry, we can’t help you,” we’ll always get back to the client, even if we don’t have an answer right away.

At the end of the day, regardless of which job I’m working, I’m fortunate enough to say that, along with my clients, I’m always smiling too.  At the end of a long day on the river, I smile when I hear the excitement in people’s voices at the end of a white water trip, as they recount every rapid and say they can’t wait to call their friends to tell them all the details. And, when I’m catching the train home after a day at Algonquin Studios, I’ve always got a smile on my face because I know that I worked hard and was able to help my clients handle the bumps in their operations and achieve their goals for a successful business day!

The Often-Overlooked Value Of A Quality Support Team

My team and I are software support representatives – when end users struggle with issues they can’t resolve themselves or encounter bugs or glitches, they call us.  We’re the first line of defense – being there for our customers and putting their minds at ease.  Over the past year, I’ve learned a lot about why the position I hold is necessary (and I’m pretty sure the developers we help would agree).

Frustrated customers don’t remain customers for long:

This one should be fairly obvious.  If a product or service you’re using causes you more grief than benefit, you’ll probably stop using it.  When a support call comes in, it’s the support representative’s job to provide the feeling that someone associated with the product cares about the customer’s issue.  If the end user is forced to leave a voicemail and wait for several hours before hearing a response, they might begin feeling like their problem will never get fixed.  No one ever wants to feel as if they are being ignored when they have a problem; letting customers fend for themselves is bound to have them looking for alternatives.

Support representatives are the face of the company:

Support reps are frequently the first people to have contact with a customer, and first impressions can be everything. A positive experience can make the customer feel confident that their issue will be addressed quickly.  A negative experience, however, can deter the customer from calling again.  Although support representatives often make up a very small part of a company, they’re usually closely associated with a customer’s opinion of the entire organization.  When a customer hears my voice, they have something tangible to associate with their product and my demeanor can set the tone for their continued relationship with the company.  Ideally, you want the person on the phone with your customer to be caring, kind, and patient, so the relationship will be as well.

Developers often don’t mix with customers:

While it’s not true in every circumstance, there are a lot of developers who don’t necessarily want direct contact with the customer. Certainly, it’s tough to concentrate on coding if your phone is ringing several times an hour, but developers can also suffer from being too “sophisticated” for their own good (and the clients’) – since they’re surrounded by colleagues who understand complex processes, it can be difficult for them to put a description into layman’s terms for an end user. Software support provides a bridge between end user and developer; the reps have enough technical know-how to work with the developers on more complex issues, but can easily relate to struggling (and, sometimes, impatient) customers.  Plus, I know some developers who just “don’t like talking on the phone” and that’s not the kind of person who should be communicating with customers on a daily basis.

Support representatives take pressure off developers:

This is obviously related to my previous point, but important nonetheless. When a customer loses patience (and nearly everyone does, at some point), they can lash out.  Support representatives are trained to handle this pressure and work to prevent it from reaching the developers. The goal of the development team needs to be producing quality software; the goal of the support reps needs to be managing the expectations of customers and helping them resolve problems quickly and with minimal pain.

It’s no coincidence that the most profitable companies have excellent support teams to back up their excellent products.  Now more than ever, these companies have come to realize that without a strong, committed support team, there would be no customers to support.  Don’t underestimate the value of a great relationship with your customer!