<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Is There a Case for Direct Connect in Today’s World?</title>
	<atom:link href="http://servicestrategies-blog.com/?feed=rss2&#038;p=166" rel="self" type="application/rss+xml" />
	<link>http://servicestrategies-blog.com/?p=166</link>
	<description>Blog by Service Strategies</description>
	<lastBuildDate>Tue, 29 Jun 2010 05:37:36 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Julian Eames</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-534</link>
		<dc:creator>Julian Eames</dc:creator>
		<pubDate>Tue, 19 Jan 2010 18:29:33 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-534</guid>
		<description>I aso believe that a mixed model is the right answer certainly for F5;

Online support tools are key to push information out into th technical community.In an online world many devlopers prefer this route to resolving their questions, On linesupporttools are particularly useful when language is an issue.  Although we cover 10 different languages there isstill a lot of languages left over.

The multiple team arguement is very valid when products are both complex and varied. A datastorage case is very differnt to a networking case. Although there are some engineers who can cover tha range when you and language to the mix it is pretty well impossible to give a good levl of service without a fom of front end load balancing. personally i prefer that interface to be human rather than an insurance model of &#039;push 2 for paymentment options&quot; on the telephone.To make this successful the front end needs to be well staffed , have set good expectations set and for  severity one cases:

Be able to pass the case directly to the correctly skilled. When you produc is in a mission critical environment this is the only acceptable level of service to enterprises who rely heavily on your product to meet their financial goal. To the point we get asked to sit on conference bridges even when the issue is not with our product.

Can you chrge a premium for this level of service ?Typically yes but competition does come into play.</description>
		<content:encoded><![CDATA[<p>I aso believe that a mixed model is the right answer certainly for F5;</p>
<p>Online support tools are key to push information out into th technical community.In an online world many devlopers prefer this route to resolving their questions, On linesupporttools are particularly useful when language is an issue.  Although we cover 10 different languages there isstill a lot of languages left over.</p>
<p>The multiple team arguement is very valid when products are both complex and varied. A datastorage case is very differnt to a networking case. Although there are some engineers who can cover tha range when you and language to the mix it is pretty well impossible to give a good levl of service without a fom of front end load balancing. personally i prefer that interface to be human rather than an insurance model of &#8216;push 2 for paymentment options&#8221; on the telephone.To make this successful the front end needs to be well staffed , have set good expectations set and for  severity one cases:</p>
<p>Be able to pass the case directly to the correctly skilled. When you produc is in a mission critical environment this is the only acceptable level of service to enterprises who rely heavily on your product to meet their financial goal. To the point we get asked to sit on conference bridges even when the issue is not with our product.</p>
<p>Can you chrge a premium for this level of service ?Typically yes but competition does come into play.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hamilton</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-533</link>
		<dc:creator>John Hamilton</dc:creator>
		<pubDate>Mon, 18 Jan 2010 19:57:30 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-533</guid>
		<description>Randy, It appears that you believe there is great value in offering a Direct Connect option, especially for Premium level customers. Definitely agree that it is essential for being responsive for mission critical applications. SaaS support does lend itself to having a direct connect chat option built into the product.

Thanks for your comments
John</description>
		<content:encoded><![CDATA[<p>Randy, It appears that you believe there is great value in offering a Direct Connect option, especially for Premium level customers. Definitely agree that it is essential for being responsive for mission critical applications. SaaS support does lend itself to having a direct connect chat option built into the product.</p>
<p>Thanks for your comments<br />
John</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Randy Fisher</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-532</link>
		<dc:creator>Randy Fisher</dc:creator>
		<pubDate>Mon, 11 Jan 2010 20:46:02 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-532</guid>
		<description>Great feedback so far, thanks for posting this John.
I believe there is still a need for direct connect support for many areas of customer need.  Direct connect complimented with skills based routing systems can provide extreme value.  This is clearly a more expensive delivery method and should allow for premium pricing that, with a reasonable attach rate, should allow for funding the delivery.  Having direct connect is also an option many customer in mission critical environments still require.

Since this is viewed as a premium support delivery option most customers do not balk at paying for it.  Offering direct connect is also a great vehicle for SaaS companies to create a fee based offering and increment their installed base revenues.</description>
		<content:encoded><![CDATA[<p>Great feedback so far, thanks for posting this John.<br />
I believe there is still a need for direct connect support for many areas of customer need.  Direct connect complimented with skills based routing systems can provide extreme value.  This is clearly a more expensive delivery method and should allow for premium pricing that, with a reasonable attach rate, should allow for funding the delivery.  Having direct connect is also an option many customer in mission critical environments still require.</p>
<p>Since this is viewed as a premium support delivery option most customers do not balk at paying for it.  Offering direct connect is also a great vehicle for SaaS companies to create a fee based offering and increment their installed base revenues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hamilton</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-531</link>
		<dc:creator>John Hamilton</dc:creator>
		<pubDate>Mon, 11 Jan 2010 20:26:59 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-531</guid>
		<description>Tom,
You make some very interesting points. The key is to provide responsive service regardless of whether the primary channel is phone or web. In your case, Mentor did an excellent job transitioning clients to the web (SupportNet) channel, whilst maintaining high response rates. 
Appreciate your comments

John</description>
		<content:encoded><![CDATA[<p>Tom,<br />
You make some very interesting points. The key is to provide responsive service regardless of whether the primary channel is phone or web. In your case, Mentor did an excellent job transitioning clients to the web (SupportNet) channel, whilst maintaining high response rates.<br />
Appreciate your comments</p>
<p>John</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tom Floodeen</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-529</link>
		<dc:creator>Tom Floodeen</dc:creator>
		<pubDate>Wed, 30 Dec 2009 17:39:04 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-529</guid>
		<description>John,
Another point I would like to make about Direct Connect.  We found that it was less efficient because it tied individuals to the phone rather then allowing them to do what they needed to do to get issues in their backlog addressed.  Since we had people on the phone in shifts, and the phone was answered by whoever was on shift, it did not allow for swarming.  By this I mean, when the phone rang, the person on shift answered it, whether they were the best one to take it or not.

By sending everyone through the web first, they have a 70% chance they will find their answer within seconds. For the 30% where they do not find their answer, a simple mouse click escalates it to the same team that used to answer the phones.  Except now the entire team sees the Service request come in and the agent with the best fit can pick it from the queue.  This avoids the many instances where the case first went to someone else and then eventually got re-assigned to the right person.

Of course this only works if the response back to the 30% is fast. We track our response rates and try to keep them below a 10 minute average. We have received many compliments from our customers about the fast response to their web submitted question.

As you say in one of your responses, the proof is in the customer opinions.  We gather and review them often to ensure we are still driving a high level of satisfaction.</description>
		<content:encoded><![CDATA[<p>John,<br />
Another point I would like to make about Direct Connect.  We found that it was less efficient because it tied individuals to the phone rather then allowing them to do what they needed to do to get issues in their backlog addressed.  Since we had people on the phone in shifts, and the phone was answered by whoever was on shift, it did not allow for swarming.  By this I mean, when the phone rang, the person on shift answered it, whether they were the best one to take it or not.</p>
<p>By sending everyone through the web first, they have a 70% chance they will find their answer within seconds. For the 30% where they do not find their answer, a simple mouse click escalates it to the same team that used to answer the phones.  Except now the entire team sees the Service request come in and the agent with the best fit can pick it from the queue.  This avoids the many instances where the case first went to someone else and then eventually got re-assigned to the right person.</p>
<p>Of course this only works if the response back to the 30% is fast. We track our response rates and try to keep them below a 10 minute average. We have received many compliments from our customers about the fast response to their web submitted question.</p>
<p>As you say in one of your responses, the proof is in the customer opinions.  We gather and review them often to ensure we are still driving a high level of satisfaction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hamilton</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-498</link>
		<dc:creator>John Hamilton</dc:creator>
		<pubDate>Wed, 16 Dec 2009 18:12:56 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-498</guid>
		<description>Jesus,
Thanks for sharing your actual experience. It does appear that the Direct Connect model did enable you to increase customer satisfaction at a lower operating cost.</description>
		<content:encoded><![CDATA[<p>Jesus,<br />
Thanks for sharing your actual experience. It does appear that the Direct Connect model did enable you to increase customer satisfaction at a lower operating cost.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jesus Blasquez</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-495</link>
		<dc:creator>Jesus Blasquez</dc:creator>
		<pubDate>Mon, 14 Dec 2009 19:33:28 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-495</guid>
		<description>A few years we insitutted a tier support model, in advertently our client felt that they could no longer talk to a support specialist. Our client satisfaction suffered and we noted an increase in the total amount of time we were having to spend on each support case. Since we are a healthcare software manafacturer with very complex cases, going back to more direct support has actually decreased our total cost for support and allowed us to close cases quicker with higher client satisfaction.</description>
		<content:encoded><![CDATA[<p>A few years we insitutted a tier support model, in advertently our client felt that they could no longer talk to a support specialist. Our client satisfaction suffered and we noted an increase in the total amount of time we were having to spend on each support case. Since we are a healthcare software manafacturer with very complex cases, going back to more direct support has actually decreased our total cost for support and allowed us to close cases quicker with higher client satisfaction.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hamilton</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-492</link>
		<dc:creator>John Hamilton</dc:creator>
		<pubDate>Thu, 10 Dec 2009 19:10:09 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-492</guid>
		<description>Terri,
You make some great points. Clients want choice and we need to provide a variety support channels to meet their preferences.</description>
		<content:encoded><![CDATA[<p>Terri,<br />
You make some great points. Clients want choice and we need to provide a variety support channels to meet their preferences.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Hamilton</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-491</link>
		<dc:creator>John Hamilton</dc:creator>
		<pubDate>Thu, 10 Dec 2009 19:05:20 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-491</guid>
		<description>Geoff,
Agree, those client conversations are very important. Besides being an integral part of the support process, they provide meaningful feedback on how customers are using your product.</description>
		<content:encoded><![CDATA[<p>Geoff,<br />
Agree, those client conversations are very important. Besides being an integral part of the support process, they provide meaningful feedback on how customers are using your product.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Geoff Rotunno</title>
		<link>http://servicestrategies-blog.com/?p=166&#038;cpage=1#comment-489</link>
		<dc:creator>Geoff Rotunno</dc:creator>
		<pubDate>Tue, 08 Dec 2009 23:59:46 +0000</pubDate>
		<guid isPermaLink="false">http://servicestrategies-blog.com/?p=166#comment-489</guid>
		<description>For us, the self service option done right is a legitimate and complementary support channel: meaningful to clients because it solves - and beneficial to us because it saves on direct connect costs (and thus, preserves/improves service levels as a result). However, at the end of the day, the rewards we reap from the conversation - the two-way, meaningful exchanges of every day, with our prospects and base, is what continues to contribute to our accelerating growth and our standing.</description>
		<content:encoded><![CDATA[<p>For us, the self service option done right is a legitimate and complementary support channel: meaningful to clients because it solves &#8211; and beneficial to us because it saves on direct connect costs (and thus, preserves/improves service levels as a result). However, at the end of the day, the rewards we reap from the conversation &#8211; the two-way, meaningful exchanges of every day, with our prospects and base, is what continues to contribute to our accelerating growth and our standing.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
