Kinetic Data Support Team

Any good relationship starts with introductions, so let’s get started. Here’s DSCF6621a bit of information on the four of us that handle support. Next time you contact support, hopefully you can have a better personal connection with the person helping you.

Name: Derick Larson

Years at Kinetic Data: 13 (worked for Insurance and Retail before KD)

Favorite Part of Support: Seeing the crazy things customers do with our products. A Time Tracking application using Kinetic Request is my favorite. Second place has to be taking inventory using hand scanners and Kinetic “Survey” templates. Continue reading “Kinetic Data Support Team”

Better Service Visibility = Better Delivery!

Service disruption occurs when change and release management collisions occur.

How do we prevent these collisions from occurring in the first place?

Even the most sophisticated teams are subjected to these problems; why?

No matter how much planning and automation you have, there are still outages!

Now the service desk is getting hammered with calls and a VP is irate over not being able to reach his “key” system. No one is happy. The world is on fire!

We planned. We strategized… We have GREAT tools! We have GREAT PEOPLE! We AUTOMATE!!!

Why? Why me? Why us?

While you may have planned accordingly, followed the good practice handbook to the letter and thought you understood the decisions in the CAB, you still had collisions. Why?

Because you made decisions based on incomplete information.

There are MANY systems of record that hold critical information related to service delivery. That information is often not all in a single database — such as your ITSM system.

Vacation and business event information? It’s in your messaging system (Exchange).

Customer specific case information? It’s in your CRM (

Release information? It’s in your ITSM system (ServiceNow).

If key data related to change/release decisions is not all in the same system, the effort to correlate it may be painful and time-consuming, but; ultimately it is worth it if service is improved. Figure out how to get it correlated — even if it is a spreadsheet. Reduce the risk by knowing what is what.

1:56 — A demonstration of a unified calendar view.

We built Kinetic Calendar to enable real-time visibility into key data from multiple applications. it’s more important than ever to be able to cross reference data from those systems. Request a free demo here.

What’s New on Kinetic Community – May 2015

Kinetic Community is the information and interaction hub for users of Kinetic Data software. It’s the place to find and discuss product documentation, videos, presentations, training class materials, downloads, example service items, task handlers, bundles, bridges and more—as well as presentations from the 2015 Kinetic Enthusiasts Group (KEG) event. As John Sundberg notes in the video below, Kinetic Community is a fantastic asset.

Kinetic Community rocks - create, share, and smileHere is what’s new on the site since our last blog update: Continue reading “What’s New on Kinetic Community – May 2015”

What’s New on Kinetic Community – August 2013

Kinetic Community is the information and interaction hub for users of Kinetic Data software. It’s the place to find and discuss product documentation, videos, presentations, training class materials, downloads, example service items, task handlers, bundles, bridges and more.

Kinetic Community
Here is what’s new on the site over the past 30 days:

Implementing a Multi-Language Survey (August 21, 2013)

There are two main methods of implementing a multi-language survey, each with its own pros and cons, but making framework changes to support multi-language surveys is a bit more involved than simply cloning the survey and changing the displayed text. This article will focus on how to implement framework changes to enable multi-language surveys.

Arranging Checkbox Answers in Multiple Columns (August 20, 2013)

When you have a large number of checkboxes related to a single question, their arrangement on the page can become unwieldy and ugly. This solution article explains how to collect the answers in a multiple-checkbox List field and arrange them in parallel columns using JavaScript.

Putting Answers into Mobile-Friendly Tables (August 19, 2013)

The simple service item described in this article illustrates using a customer’s answers to build up a table in Kinetic Request.  This enables the customer to request multiple items (ex. Port details for a Server Add Request) without having to have multiple instances of the same field (ex. Port Type and IP Address) on the service item.

LinkedIn Handlers (August 15, 2013)

These two LinkedIn handlers allow you to post a comment along with corresponding web content to both an individual and a company’s profile. This web content url can be posted along with a Title, a Description, and an Image Url.

Twitter Handlers (August 15, 2013)

These two Twitter handlers allow you to post statuses of differing complexities to Twitter. One handler will post a text only status while the other one allows you to post a picture in jpg, gif, or png format.

Populating a Mobile-Friendly Table Using a Simple Data Request (August 13, 2013)

The service item described in this article illustrates using Simple Data Request to build up a table in Kinetic Request.  Once loaded, the sample service item uses the Simple Data Request framework to retrieve a list of User records and display a table of Create Date, Modified Date, Email, Login Name, and Full Name field values.

Data Pull (August 7, 2013)

This package contains the files necessary for displaying results from Kinetic fulfillment records (approval, work order) in the customer’s review request. This allows the customer to view fulfillment information without creating duplicates of all the fulfillment answer in the original request.

SMTP Calendar/Meeting Invite Task Handler (July 30, 2013)

This handler builds and sends an email with an icalendar meeting request invite directly to the specified email server specified by the associated task info values.

To learn more, check out all recent updates and resource additions on Kinetic Community.

The ROI of IT Support Improvements (Think Big)

It’s hardly news to point out that service desk improvements provide numerous benefits to an enterprise: happier employees, reduced downtime, more time for IT staff to focus on strategic priorities.

And it’s intuitively logical that improving support processes saves money. What may be surprising, however, is the level of cost savings that can be achieved across a large organization through even small improvements in support practices.

According to research from MetricNet, reported in the white paper The Economic Impact of Support, the average cost of an IT support ticket starts at about $22 for Level 1 (service desk) support and rises dramatically as issues are escalated, reaching $196 per ticket for field support and a whopping $471 for vendor support.

Costs of Service Call Escalation
Image credit: MetricNet















Of course, some issues need to be escalated. But the white paper focused on the cost of escalating tickets that could have and should have been solved through first-level support. Such issues exist in every large organization. The good news is that, because of the steep cost rise as tickets are escalated, improving service desk practices to resolve more Level 1 issues at the service desk can yield enormous returns.

As the white paper notes, “The difference between the top- and bottom-quartile performers is a staggering thirty hours per employee per year! Put another way, support organizations in the top quartile are able to return nearly four extra days of productivity annually for every knowledge worker in the enterprise. When multiplied by thousands or even tens of thousands of employees in a company, the productivity gains and ROI delivered by a top-performing support organization can be tremendous!” In the case of the insurance company profiled in the report, the cost difference of being a top-quartile performer vs. a bottom-quartile company amounted to more than $6 million annually.

So how can an organization improve help desk processes to achieve that kind of cost reduction? One key strategy is to address gaps in service delivery processes incrementally. By making a series of small changes, rather than attempting a single “big bang” overhaul of IT support, staff remain motivated by achieving and celebrating a succession of small victories.

For more ideas, check out Five Steps to a Better Service Desk on

Building a Better IT Service Desk, Revisited

A while back–a few years ago actually–Kinetic Data president John Sundberg wrote an article for SupportWorld magazine titled 5 Steps to a Better Service Desk. The article was later posted on the Kinetic Data website, where it got an initial surge of visitors and then continued to attract a modest number of readers month after month.

Then something interesting happened. Visits to the article page roughly quadrupled between December 2011 and March 2012 (from 32 to 124). And they kept increasing, doubling over the next two months then doubling again by August 2012, to 509 visits. Pageviews topped 1,000 last November, and exceeded 1,200 in April 2013, making this article one of the most-read pages on the site, along with the home page and the IT service management glossary page.

Improving the IT Service DeskWhy? First, the page has struck a chord with searchers. Roughly 85% of visits to the article are the result of people searching for terms like “help desk improvement plan,” “service desk improvement ideas” and “how to improve a service desk.” Technology is vital to business success, and as the corporate IT landscape has become more complex due to trends like BYOD and mobile workers, managers need to adapt to support workers’ increasingly reliance on technology.

Second, despite rapid technological change, much of the guidance in the article is timeless. For example, among the recommendations are:

Use surveys and metrics to support continual improvement. “When patterns surface—through survey results, complaints, or service desk personnel—it’s time to kick into improvement mode. That means amending staffing (training/coaching/replacement), process (create a workaround or a new process for performing a specific function), technology (develop a fix), or a blend of these areas. What’s important to keep in mind with respect to continuous improvement is that after the change is implemented, metrics must be monitored for signals that the change resolved the issue.”

Shorten and simplify improvement projects. “The most common reason that improvement projects stretch beyond initial time estimates is waiting for the new process to be totally complete before using it. It makes good sense to start testing early, on a limited basis, to find out what works and what doesn’t. In an innovative culture, communication sets the stage for an early introduction that will expose problems and mistakes and enable quick corrective action. It’s better to implement half of a solution that solves part of the problem (and yields some benefit) than to wait an inordinate amount of time to solve the entire problem.”

Use hiring, training and communication to create a culture of innovation. “One of the clearest indicators of success is a high level of enthusiasm about a project—within the service desk team, throughout the company, and across the external user audience. Before and during a project, promote the benefits that will impact internal and external customers. Provide updates through a regular report or newsletter to rally the troops.”

There’s no question that specific help desk practices have changed significantly over the past half-dozen years, as smartphones have proliferated and their capabilities have expanded while the expectations of business users have continued to evolve for mobile and remote support.

The core principles of improvement, however–such the importance of measurement, simplification, and celebrating successes–remain as relevant to the IT service desk today as ever.

Learn more with these white papers:

Using Service Catalogs to Run IT As a Business (Not Like a Business)

Say Goodbye to the IT Service Management Queue

What is this “Level 0” thing? (Part 2): Knowledge, Self-Analysis and Feedback

Tools of the Trade (Part 2)

A Vision From Down Under
By Michael Poole

In my last blog, I mentioned a major client who is ‘shifting to the left’ and implementing ‘Level 0’ methods.

For those who missed my last blog, in short, ‘Level 0’ is the process of enabling users to resolve their own incidents and requests.

Obviously, one way of implementing ‘Level 0’ is to shut off the phone lines and email addresses of the Help Desk. A very effective way of getting users involved in the process, but not one I would recommend to anyone wanting a long future in an organisation. Of course, sometimes we implement this method by under-resourcing our support teams – but that is the subject for another blog.

To implement ‘Level 0’, users have to have the information available to them to resolve issues as they arise. So how do we give these to them.

There are a number of tools available.

The Knowledge

It has been famed around the world that London cabbies spend years “doing the knowledge” — learning every street, lane, theatre, hospital and pub in London — before they can sit for the exam to obtain a cab licence. Do we need to ensure that before any person joins the organisation they have an intimate knowledge of computer hardware, software, networking etc.?

No, because now, they can be like today’s Sydney cabbies who avoid “the knowledge” by having a SatNav or GPS system in the cab. Our users’ SatNav can be a Knowledge Base.

The move to implementing “KCS” or Knowledge Centred Support has been going for a number of years, but for many organisations, this has been limited to building knowledge bases directed at and only available to the support team — not the user. With the development of Web 2.0+, users are becoming more accustomed to “googling” for solutions and answers and also using self-help resources that are a part of the major social media sites. I admit, in doing these blogs, I have often consulted the blog site’s help pages and Support Forums.

So KCS is one of the tools that can be deployed as part of the “shift to the left.” But to do this, we have to make sure that we develop our KCS articles, not for computer engineers, or if we are deploying across an enterprise , HR experts or accountants etc, but for the average user and common issues.


No, I’m not becoming Tony Robbins — all “SHAMish” (Self Help and Actualisation Movement) — perish the thought — or bringing Freud onto the Help Desk — even though at times he might be useful in dealing with users, but more IKEA!

The results of some IKEA assembly projects might belie the concept — but I assume that they have more successes than failures through the step-by-step self-assembly process.

A few — well maybe many — years ago, I was involved in a project that required me to have what is called an “Assumed Rank” in the Australian Armed Services. I made Colonel for a month — the duration of the contract — but thankfully did not have to do the physical, wear a drab khaki uniform, bear arms or be saluted. But I did get into the Officers’ Mess and people had to answer my questions in a respectful way, but that is past. What I did get to find out was how the most complex maintenance and repair processes for a fighter jet could be broken down into simple steps and documented so that even I could have replaced, as an instance, the wiring loom on an F-111 or the laser-guidance system. The “repair manual” — and it was all hard-copy — was contained in a room-full of filing cabinets and needed a librarian to keep it in order and up-to-date. This of course was an extension of the production line methodology introduced by Henry Ford at his eponymous company to make the most complex consumer engineering  product of the day — the motor car — with relatively unskilled workers. Other car makers of the time were using skilled engineers and coach-makers to make one car at a time.

As the makers of the F-111 and Henry Ford knew, every process can be broken down to simple steps and delivered in an appropriate way to produce a complex result. For Ford this was a car; for General Dynamics it was the F-111 repair manual; for us this can be a fault-finding and resolution process.

In fact for the client mentioned above, we implemented such a system — a fault-finding process that enables staff with little or no technical knowledge to analyse and, in over 30% of cases, resolve issues with lap-tops ranging from OS to wireless network issues through a series of simple steps that relied on the answers to a number of questions and test activities that they could understand and carry out.

So another tool in the “Level 0” process, is intelligent and responsive self-analysis and resolution tools. What is sometimes called an “expert system.”

Information, Contribution, Monitoring & Feedback

Implementing “Level 0” also requires openness of information and a positive response to user feedback.

Users should be given every opportunity to be a part of the process.

Where KCS is implemented, users should be able to rate and suggest improvements to KCS articles and guides and also author and submit new KCS articles. As well as providing another source of input into the KCS system, users will develop a group ownership of the KCS system and its acceptance will be more easily gained.

This is also true of any self-analysis and resolution process. A network engineer may be able to define the step-by-step process for resetting a head-end switch, but it may take some input from an end-user to enunciate the process in easily understood vocabulary or point out areas that need better definition.

Users must also be contribute to the areas that need to be covered in the KCS or self-service system. What the experts think are trivial matters, may be a source of confusion to users.

Access to monitoring information in a easily understandable format can reduce calls on the Service Desk. If users know that a system is down for maintenance then they have no need to log a call.

And of course feedback to users is essential when they make a contribution or highlight an area that needs better coverage.

In part 3, I will look at ways to integrate these tools into web-based portals that can be deployed to users.





Eliciting Requirements for a Successful IT Project

By Greg Johnson

If we built houses instead of technology solutions, would your project sound like this?

Dear Mr. Architect,

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion based on what works for other people.

My house should have between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or removed.

As you design, also keep in mind that I want to go green as much as possible. This should mean the incorporation of sustainable, earth friendly materials. (If you choose not to use hemp in the insulation, be prepared to explain your decision in detail.)

I’m sure I can trust your expertise and professionalism. Be alerted, however, that the kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

To ensure that you are building the correct house for our entire family, make sure that you contact each of our children and also our in-laws. My mother-in-law will have strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

Please don’t bother me with small details right now. Your job is to develop the overall plans for the house—get the big picture?

Also, do not worry about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans however, I would expect the blueprint delivered within a week.

While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. Therefore, it should appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features of this house. Oh, and the turret shaped corner on the front is a must have!

I advise you to look at my neighbor’s house constructed last year. We like it a great deal. It has many features that we would like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

You must be thrilled to be working on an interesting project like this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can’t happen very often. Contact me as soon as possible with your complete ideas and plans.

PS: My wife has just told me that she disagrees with many of the instructions I’ve given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can’t handle this responsibility, I will have to find another architect.

PPS: Maintenance free is the way to go. i.e., why should I have to turn “on” the dishwasher? Shouldn’t it know when it’s full?


Yes, Mr. Architect should run; not walk away from this one but we don’t always have that option, do we? Many of us only have the one customer, so we have to find a way to elicit our requirements in a way that makes the project successful.

Elicit isn’t a common word, but it’s important to use because we are talking about going beyond mere requirements “gathering”. If we only gathered the requirements we would take what is given at face value and start building something. In order to elicit, we must go further to reach a common understanding with the customer that sets the expectations in a documented way.

Start with People

Starting with where this project is coming from, you probably know who your customer is. From there you can identify the stakeholders by asking who is it for, who is affected by it, who will use it, who’s in charge of it and who needs to know about it. You will want to set up interviews with those key stakeholders who have information you need, or have authority to make decisions for others. Interviewing also gives you a chance to identify conflicting ideas and set reasonable technical expectations. Another good idea is to get the stakeholders together for a brainstorming session. This process is a science of its own but the goal is to narrow things down so that everyone is more or less on the same page going forward.

Use Cases

Once you have your input from all the stakeholders, it’s a good idea to walk through the process by documenting informal use cases. Make sure you encourage your stakeholders not to get too caught up in the technology at this point, but to write down each case like a story. Getting people to think about a use case helps flesh out other requirements and refines the business process.


Most technology projects are severely lacking in this area and that’s too bad because it really helps nail down requirements. I suppose it’s because customers don’t want to pay for it and developers don’t want to spend time on something that’s just going to get scrapped later. As a developer, I admit I’m not too keen on it either but consider this—when you have a customer that doesn’t know what they want, this helps them get there. They may need to use the new software (with its associated process changes) before they discover additional valuable functionality and features. If the software itself isn’t available, just mocking up some screen shots might be adequate. Prototyping also helps identify those oversights the customer didn’t include so that they don’t turn up in UAT.  You’ve never had that happen, have you?

Assessing Feasibility

This is a two-pronged review process, which involves both customer and developer.  The customer’s task is to review the business process to make sure the requirements will meet the business goals. At this point it may be useful for them to review their business plan, market analysis, and other documents to determine if this project fits within that framework.

The developer looks at the project’s requirements to see if it’s feasible based on the technology available. It may be necessary to pull in other products or people and make the customer aware of this so they can let go of certain requirements if the cost is too high.


Once your requirements are all pulled together, it’s time to write them all down for all to review and ponder. The main purpose of requirements documentation is so that everyone knows what to expect going forward. You and the customer will probably find yourselves referring back to them as the project moves along, so take the time to be thorough and clear. From your perspective, you want to minimize scope creep. If you think of anything that you’re not sure needs to be written down, write it down anyway. Sometimes it’s helpful to also include what things are NOT included so that it can be there for reference later.

Now that you have elicited your requirements, take a step back and reflect on what you’ve accomplished. Do you feel good about it? If so you have laid the foundation for a smart and successful project!