I am new to official support, It say’s 3 business days, but obviously that’s wishful thinking. Can someone experienced give me the average wait time for such a request.
Thanks,
Three days, means the time it takes them to process the email and start looking at the issue.
However realistically, the wait time is a complex formula.
See problem + write up email with supout + 3 days + fix in firmware + release in firmware = XXX days.
(at least I didnt put XXXX days) 
It close to XMAS, so its get Normis’ children, the legitimate ones presents, or address your concern… (visualize moving ones hands up and down to weigh the consequences of either action)
Its now winter in Latvia, they have very little light (dark most of the time) and thus there is not that much time to read the printouts! ( yes Normis watches the electricity bills closely)
You dont think Normis lets his staff or firmware anywhere near LIVE INTERNET computers.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Seriously,
Probably a factor of getting around to the issue, there will be a stack, and how easy or hard it is to recreate/reproduce the issue and then to understand the root cause (via some level of analysis) and then a review process internally on what to send external from the company.
I am not looking for a timeline of a fix, just an acknowledgment of the problem and whether they can reproduce it or if I need to provide more info / try some troubleshooting steps.
Mention it here. Start a new thread.
Most likely someone encountered the issue as well.
Maybe some even know a work around already…
Yeah thats what we want, everyone one whining about the problem they submitted further polluting the forums.
Why not have a read only ticket system MT link, that people can simply check progress, oh wait, its still the 1990s??
Number one on the xmas wish list.
Punch cards.
True read only…
Although.. in some cases they COULD be modified if you were lucky 
As you can see in the picture of the ticket, all the issue’s started in the forums and went unanswered so they got upgraded to official support.
Sorry, couldn’t see the contents of that picture on my smartphone.
Each ticket is assigned a category and then handled by a specific specialist. You can’t just dump all kinds of random issues into one complaint, this is why your ticket got stuck in the system. Please report each bug separately.
Too funny Normis, at work we use ARAS enterprise software to handle all issues, and after writing up a validation of the issue, and prior to sending to the contractor, it gets vetted for technical inspection by our engineers, initially the number one show stopper was multiple issues. Its a ton of work to split up an operational problem into its component parts ESPECIALLY if one is not the originator, so I feel your pain.
Well, I mean, you can do that, but to get an answer quickly:
- make a clear and short description of the issue (no links to forum, or “i have same issue as those guys”)
- include your configuration
- if possible, include clear steps how to repeat it
- each issue into a separate ticket
This will make it much faster to get an answer and hopefully get a fix for your bug.
100%
From our perspective we want to provide the full context to the contractor, but we also want to ensure the contractor is focussed on a single digestible issue.
Since the $$ to do work is pre-paid/fixed, any other process will mean less than optimal use of said funds. Hence our operational validation has to be reviewed from the technical aspect to ensure the issue is clear, will be understood, and is targetted.
I still think that a ticket system should be public facing, in terms of allowing those with a login to the troubleshooting system, can view a READ ONLY status of tickets.
Ticket# / Title / Date submitted /Status / **Projected Build inclusion if valid /
Once a status is something like Verified (issue replicated), then a projected build could be entered.
Maybe pointing that out when it was first noticed would of been more productive then waiting for me to complain on the forum. 
The onus is on you to learn how to report issues, not for Normis’ team to respond to each ticket and user etc…
However, the ticket system I suggested would bridge the divide so to speak.
This is just off the cuff…
I think the whole point of “support” has eluded you. If there is any type of specific requirements/rule’s they need to be told to the end user requesting support before the ticket is made. Having a secret set of rules, and not responding to ticket’s that do not meet those rules just make you look like an ass. and saying it’s my job to figure out these secret rules just makes you sound like a dumb ass. I am not sure if you are familiar with how ticketing systems work but this issue is easily avoidable.
Here is the current rules as of this post:
Well the ref quoted does say “your issue” which is singular, not my fault you are illiterate and provided multiple issues on one ticket.
I know your trying to redeem yourself, but your just not there. Maybe next time.
I highlighted the important parts for you.
You are wasting your time, I do this for a living…
A BUG moron! Not YOUR BUGS!!
The problem set describes the operational impact to your work due to the bug…
That provides context to how the feature (singular) is NOT working and how it is preventing your configuration from working.
You get stuff wrong for a living? What are you a meteorologist?
@anav: If you do user support, then I get how it can make one hate users will all heart, but aren’t you supposed to still stay somewhat user friendly?