<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0" xmlns:s="http://www.techrepublic.com/search" xmlns:dc="http://purl.org/dc/elements/1.1/"  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
    <title><![CDATA[Discussion on Creating a process for fault resolution ]]></title>
    <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271]]></link>
    <atom:link rel="hub" type="application/rss+xml" href="http://pubsubhubbub.appspot.com/" />
    <atom:link rel="self" type="application/rss+xml" href="http://www.techrepublic.com/forum/discussions/102-307271/rss" />

    <description><![CDATA[]]></description>
    <language>en-us</language>
    <lastBuildDate>2013-05-19T05:43:02-07:00</lastBuildDate>
             

    <item>
        <title><![CDATA[Would you like fries with that?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3111822]]></link>
        <description><![CDATA[I have read numerous postings like these. I have always found the same problem occurs. Whether people would like to admit or not a technical service desk is different from a help desk. While they perform similar in scope, there has been a shocking increase in trying to mush one into the other for processes and procedures. This causes what I like to call, the Fast Food Tech effect, where the focus is on speed and creates unrealistic expectations on the customer end as it portrays the image that technical support fixes are quick fix solutions (and consequently employee burnout). This in turn makes the client unhappy with the service (as they believe it is a simple fix that should be done now), puts strain on the &quot;help desk&quot; and generally degrades service across the board which is, in the long run, counter-productive. I find that the main way to differentiate between if you have a help desk or technical service desk is to ask yourself the question when hiring &quot;Do I require a person with computer education?&quot;. In the end the customer happiness is the paramount overriding factor and striking a balance of speed, quality of service and customer happiness is the eternal struggle.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3111822]]></guid>
        <dc:creator><![CDATA[Buzz09]]></dc:creator>
        <pubDate>Tue, 07 Jul 2009 08:43:51 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[.]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3111786]]></link>
        <description><![CDATA[.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3111786]]></guid>
        <dc:creator><![CDATA[Buzz09]]></dc:creator>
        <pubDate>Tue, 07 Jul 2009 08:24:35 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Creating a process for fault resolution]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3064560]]></link>
        <description><![CDATA[One suggestion we have implemented at our HelpDesk under the category of what - &quot;What were you doing at the time, what was the result, and what was the INTENDED result?&quot;For a HelpDesk such as ours that supports about 250 applications, this goes a long way to gathering the correct information to properly troubleshoot the issue.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3064560]]></guid>
        <dc:creator><![CDATA[jeremial-21966916363912016372987921703527]]></dc:creator>
        <pubDate>Tue, 28 Apr 2009 08:26:10 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[RE: Creating a process for fault resolution]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059819]]></link>
        <description><![CDATA[Jeff made a good point &amp; started the conversation off well.  Regarding scripts, I think they can be useful, but only during the Help Desk personnel's ramp up time.What we need to remember is that approx. 80% of break-fixes occur because something was changed &amp; 80% of the Mean Time to Repair is spent trying to figure out what changed.&quot;Is there anything else I can do for you today?&quot; - GREAT!!! Close out of the call a positive note.&quot;When? The time that the fault occurred...&quot; - my only suggestion is also ask - when did it work last.When my group was supporting Market Data Trading Systems, we used email to reports problems.  Whenever I received an email, I would respond back with &quot;Checking...&quot;  Even though my customers knew I was not checking at that right moment, they knew that I read their email &amp; were more understanding because we acknowledged their call for help.In other words, put yourself in the shoes of YOUR CUSTOMERS when they call for help &amp; you will be loved!]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059819]]></guid>
        <dc:creator><![CDATA[daniel.furrey@...]]></dc:creator>
        <pubDate>Tue, 21 Apr 2009 09:21:08 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Is there anything else I can help you with today?]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059820]]></link>
        <description><![CDATA[Great article, but I must disagree with you on one point.  Not only should the call taker ask, &quot;Is there anything else I can do for you?&quot;, but the tech that addresses the issue as well.  It shows you care about the customer and their issues.  Sometimes they even come back with &quot;Now that you mention it, there is this other thing...&quot;.  Now you can address an issue they may have forgotten about, which will make the customer even happier.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059820]]></guid>
        <dc:creator><![CDATA[sidekick]]></dc:creator>
        <pubDate>Tue, 21 Apr 2009 09:19:10 -0700</pubDate>
    </item>
             

    <item>
        <title><![CDATA[Quality of services]]></title>
        <link><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059109]]></link>
        <description><![CDATA[you can achieve quality of service by diffrend ways. You must always remember that at the end of the process is Your Customer. When customer has a problem he doesn't always think rational. Most of all he thinks emotional. 5xW is good way too.]]></description>
        <guid><![CDATA[http://www.techrepublic.com/forum/discussions/102-307271-3059109]]></guid>
        <dc:creator><![CDATA[gamerider@...]]></dc:creator>
        <pubDate>Mon, 20 Apr 2009 15:09:47 -0700</pubDate>
    </item>
    </channel>
</rss>

