LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

NI Support Malfunctioning

Is anyone else having problems with NI Support abandoning tickets instead of working on them?

 

Or is it just me?

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 1 of 10
(2,569 Views)

What are the ticket numbers?

 

Of course it happens but it shouldn't be typical.

Matt J | National Instruments | CLA
0 Kudos
Message 2 of 10
(2,558 Views)

@Jacobson-ni wrote:

What are the ticket numbers?

 

Of course it happens but it shouldn't be typical.


#7794213

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 3 of 10
(2,545 Views)

@Jacobson-ni wrote:

What are the ticket numbers?

 

Of course it happens but it shouldn't be typical.


Right, it shouldn't be typical.  But unfortunately, it is.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 4 of 10
(2,439 Views)

Here is how the current NI support model looks from my perspective:

  1. The customer submits a service request.
  2. The ticket is assigned to a support engineer.
  3. The support engineer e-mails a few questions.
  4. The customer answers the questions.
  5. The support engineer goes silent.
  6. E-mails from the customer to the support engineer go unanswered.
  7. The customer submits another service request asking that support be resumed on the original ticket.
  8. A different support engineer is assigned to the original ticket.
  9. Go to step 3.

I've just passed step 4 again (now on my 6th support engineer).  Maybe 6th time is the charm.

"If you weren't supposed to push it, it wouldn't be a button."
0 Kudos
Message 5 of 10
(2,418 Views)

Hi Paul, it may be related to complexity of the ticket. If it has to do with some of your XNode code (for example), there might not be as many people that can help. Or they might have to choose between closing 10 easy tickets or 1 paul_cardinale ticket. I'm not trying to make excuses for NI, just offering an explanation why your ticket gets lost while others might not. I do hope the 6th time's the charm.

0 Kudos
Message 6 of 10
(2,413 Views)

It turns out that the 6th time was the charm.

Support engineer Adam Hennad solved the problem (and rather quickly).

"If you weren't supposed to push it, it wouldn't be a button."
Message 7 of 10
(2,405 Views)

@Gregory wrote:

Or they might have to choose between closing 10 easy tickets or 1 paul_cardinale ticket. 


Yes this is becoming very common everywhere as service personal are basically internally rated and reviewed on the number of service requests CLOSED. (Complexity of the issue is not a factor on the spreadsheet some manager sees showing how many service requests you received and how many you closed in a timely manner)

 

So if your issue can't be solved in a day or two, you are going to get put on back burner because they have to close some easy tickets to keep their numbers up.

========================
=== Engineer Ambiguously ===
========================
Message 8 of 10
(2,398 Views)

I've seen an SE signature stating if I don't respond to their email within 3 days, the request will marked as resolved and automatically closed. Never mind if I'm busy, or unavailable for some reason.

 

"If there is no reply within 3 days, the service is determined to be resolved and the SR is automatically closed. If you have more questions after denoted period, you will need to request technical support again."

 

This was after more than a week of my submitting an SR and hearing nothing out of support 🤔

 

That is, if I can submit a request in the first place...

 

service request error.PNG

 

Any sort of KPI or performance indicator based on tickets closed is stupid. If there are performance metrics measured, there are performance metrics to be gamed.




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 9 of 10
(2,377 Views)

@Gregory wrote:

Hi Paul, it may be related to complexity of the ticket. If it has to do with some of your XNode code (for example), there might not be as many people that can help. Or they might have to choose between closing 10 easy tickets or 1 paul_cardinale ticket. I'm not trying to make excuses for NI, just offering an explanation why your ticket gets lost while others might not. I do hope the 6th time's the charm.


It had nothing to do with XNodes (I wouldn't even bother asking for support on XNodes); it was an app builder issue.

It turns out that if you're using LV2018 and running a Source Distribution buildspec, and VIs in your project call malleable VIs that are in your project and those malleable VIs call sub VIs that are also in your project and your buildspec has "Remove unused polymorphic VI instances" checked, then when the buildspec runs, the malleable VIs will get converted into Express VIs, and the subVI calls inside the (former) malleable VIs will be wrongly linked: They will be linked to the original versions in the project source instead of the copies in the source distribution build.  This results in a broken source distribution.  The solution was just to uncheck "Remove unused polymorphic VI instances" in the buildspec (I had tried many many things to try to solve the problem, but that never occurred to me).

"If you weren't supposed to push it, it wouldn't be a button."
Message 10 of 10
(2,357 Views)