<div dir="auto">With all honesty, if you ask me, my experience with most companies from China-in relation to Support- has always been fast and super satisfactory no matter the raised case or sensitivity of the impact to users. I have always felt comfortable running their gear and gives some sort of confidence in not having prolonged outages no matter the reasons( engineer inexperienced, not knowledgeable)</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 7 Mar 2024 at 09:49, Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">On Wed, 6 Mar 2024 at 22:57, michael brooks - ESC<br>
<<a href="mailto:michael.brooks@adams12.org" target="_blank">michael.brooks@adams12.org</a>> wrote:<br>
<br>
> Funny you should mention this now, we were just discussing (more like lamenting...) if support is a dying industry. It seems as though vendor budgets are shrinking to the point they only have a Sales/Pre-Sales department, and from Day Two on you are on your own. Dramatic take of course, but if we are speaking in trajectories....<br>
<br>
My personal experience extending in three different decades is that<br>
there is no meaningful change in support quality or amount of issues<br>
encountered.<br>
<br>
Support quality has always been very modest, unless you specifically<br>
pay to have access to named engineers. And this is not because quality<br>
of the engineers changes, this is because vast majority of support<br>
cases are useless cases, and to handle this massive volume support<br>
tries to assume which support cases are legitimate problems, which are<br>
PEBKAC and in which cases the user already solved their problem by the<br>
time you read their ticket and will never respond back. The last case<br>
is so common that every first-line adopts the strategy of 'pinging'<br>
you, regardless how good and clear information you provide, they ask<br>
some soft-ball question, to see if you're still engaged.<br>
Having a named engineer changes this process, because the engineer<br>
will quickly learn that you don't open useless cases, that the issue<br>
you're having is legitimate, and will actually read the ticket and<br>
think about the problem.<br>
<br>
To me this seems an inevitable outcome, if your product is popular,<br>
most of its users are users who don't do their homework and do not<br>
respect the support line's time, which ends up being a disservice to<br>
the whole ecosystem, because legitimate problems will take longer to<br>
fix, or in case of open source software, authors just burn out and<br>
kill the project.<br>
<br>
What shocks me more than the low quality support is the low quality<br>
software, decades pass along, and everyone still is having<br>
show-stopper level of issues in basic functions on a regular basis,<br>
the software quality is absolutely abysmal. I fear low software<br>
quality is organically market-driven, no one is trying to make poor<br>
NOS, it's just market incentives drive poor quality NOS. When no one<br>
has high quality NOS, there is no reason to develop one, because most<br>
of your revenue is support contracts, not hardware sales, and if the<br>
NOS wouldn't be out-right broken needing to be recompiled regularly to<br>
get basic things working, lot of users might stop buying support,<br>
because they don't need the hand-holding part of it, they just need<br>
working software.<br>
This is not something that vendors actively drive, I'm sure most<br>
companies believe they are making an honest attempt to improve<br>
quality, but it is visible in where investments are put. One vendor<br>
had a very promising project to take a holistic look into their NOS<br>
quality issue, by senior subject matter experts, this project was<br>
killed (I'm sure funding was needed somewhere with better returns),<br>
and the responsible senior person went to Amazon instead.<br>
<br>
<br>
<br>
><br>
><br>
><br>
><br>
> michael brooks<br>
> Sr. Network Engineer<br>
> Adams 12 Five Star Schools<br>
> <a href="mailto:michael.brooks@adams12.org" target="_blank">michael.brooks@adams12.org</a><br>
> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::<br>
> "flying is learning how to throw yourself at the ground and miss"<br>
><br>
><br>
><br>
> On Wed, Mar 6, 2024 at 11:25 AM Pascal Masha <<a href="mailto:pascalmasha@gmail.com" target="_blank">pascalmasha@gmail.com</a>> wrote:<br>
>><br>
>> Thought about it but so far I believe companies from China provide better and fast TAC responses to their customers than the likes of Cisco and perhaps that’s why some companies(where there are no restrictions)prefer them for critical services.<br>
>><br>
>> For a short period in TAC call you can have over 10 R&D engineers and solutions provided in a matter of hours even if it involves software changes.. while these other companies even before you get in a call with a TAC engineer it’s hours and when they join you hear something like “my shift ended 15 minutes ago, hold let me look for another engineer”. WHY? Thoughts<br>
><br>
><br>
> This is a staff email account managed by Adams 12 Five Star Schools.  This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender.<br>
<br>
<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div></div>