My workplace adopted some software several months ago, at the outbreak of COVID-19, to help us conduct our work remotely. The software has been extremely buggy, to the point of slowing down our productivity considerably. I am now bringing 10-15 hours of work home on weekends above previous amounts.

Since I've added so much to my at-home workload, I put much effort into filing bug reports, especially for those most serious bugs. I file bug reports for FOSS projects frequently, and usually the bugs get fixed.

The problem is, this software company requires bugs be reported as a "support ticket" and I get stuck in a seemingly endless quagmire of requests for more and more details. I post highly detailed descriptions: I'm updated, I tried it on multiple platforms, took screenshots, checked with co-workers to confirm they all have the same problem. Still, it seems never enough for the support, they want more and more information. "Try it on this browser". "Try rebooting and see if it still happens." "Make a screen recording for us". "Try it from home instead of on work servers." "Ask someone else to do X, Y, Z, and send us more screenshots..." It never seems to end, and so far they've resolved none of my issues.

I don't work in software development, I'm an educator. Is this at all reasonable that I should be expending so much effort to get serious bugs fixed?

  • 3
    When the new tool was implemented, our own IT department said they wouldn't handle any issues related to that software.
    – Village
    Commented Jan 28, 2021 at 15:48

11 Answers 11


No, it's not reasonable that a non-technical end user is asked to do so much investigation into a bug they've encountered. This sounds to me like you are stuck in a situation where everyone else involved has interests other than making sure the tool enables you to do your work.

If your IT department is not supporting it, it sounds like someone forced them to accept a tool they didn't want to use, and now they are going to stand by and let everyone suffer the consequences of that bad decision. If the software company is making you jump through a lot of hoops when you try to get technical support, it seems to me like they are trying to seem responsive so they can keep getting paid by your employer without actually having to expend any of their own resources to fix your issue.

The only solution to this is to escalate it to your management. Even though I am software developer, when I am trapped in a situation like this, I will simply refuse to jump through any more hoops after I have given them a reasonably detailed report and answered any reasonable follow-up questions. I then escalate the issue every time it impedes my work until it gets solved, I get a work-around, or I feel like someone is trying to get it solved.

Do not be rude, because often the people who are giving you the run-around are also stuck in a situation they have no control over. Just keep adding people to the CC: list until you find someone with the power to unblock you. Any time anyone tries to help me make forward progress, I make sure to let them know I appreciate their effort. Even though the situation is really frustrating, try to presume that the person on the other end of your support request actually wants to help you, but may not have the ability to through no fault of their own.

  • 15
    Arguably it's not about the interests, often the first-level support team PEBKAC type problems and completely untrained to handle actual bugs. Cisco is a famous company with that practice. The primary customer support team has no insight and possibility whatsoever to file bugs.
    – ljrk
    Commented Jan 29, 2021 at 9:35
  • 3
    @ljrk I agree, but if the company was as interested in solving a customer’s problem as having cost effective support, their frontline folks would be would be encouraged to pass problems they can’t solve onto someone who could. Instead they’re often incentivized to give customers the run around. I find most support folk I deal with truly want to help, but they also want to do well at their job, and sometimes their management doesn’t want them allowing a customer with a hard problem to suck up resources.
    – ColleenV
    Commented Jan 29, 2021 at 12:08
  • 4
    @ljrk Yeah. Long ago I had a run-in with a buggy CISCO router. They wouldn't accept it as a bug report so long as any of our in-house software was involved--it shouldn't matter where the packets came from! They finally did accept it when I figured out how to trigger it purely from the command line. (It was purely load-based, the nature of the load was irrelevant.) Commented Jan 30, 2021 at 1:43
  • 2
    A lot of companies see support as a cost, and from the perspective of accountants, you reduce costs. That usually means worse and worse quality over time. It takes deliberate focus on quality to not fall into this trap.
    – Nelson
    Commented Jan 30, 2021 at 6:45
  • 1
    @GuitarPicker It seems like the IT department’s management realizes that supporting this software is going to be a quagmire and is protecting their people. A good IT department that has the power to choose the software that the non-technical folks will use and train their in-house people to support the company’s configuration of it is worth their weight in gold.
    – ColleenV
    Commented Jan 31, 2021 at 11:05

As an developer with more than 10 years experience in handling/solving support tickets I must say you look like a dream user to me. A (non-technical) user who writes highly detailed descriptions of what's wrong, adds screenshots, is updated, checks with others if they also experience the problem, is hard to find. In a lot of cases otherwise capable and intelligent people seem unable to write a coherent story about exactly what is wrong (and I often managed to solve those problems too).

So if you experience multiple/all times that a support ticket doesn't get solved or no progress is reported on it, I think it's likely they are just stalling you and no actual effort is spent solving your problems. So the only solution seems to be is that someone with authority within your organization steps up.

  • 21
    Bug reports saying “It doesn’t work” are not unheard of. Yes, I would be very happy with this user.
    – gnasher729
    Commented Jan 29, 2021 at 9:36
  • 8
    @gnasher729 They're not even rare among people who are hired in technical roles. Case in point, the dozens of questions on the main sites each and every day that get closed because they wouldn't even include the error message.
    – Nzall
    Commented Jan 29, 2021 at 13:14
  • 2
    Totally agreed. I always ask for screenshots, even when they're "sure" that they did what I said. Sometimes I would tell them to make this specific setting change and when they say they did it and it still doesn't work, I ask them to send the screenshot of the settings. 9 times out of 10, they didn't do what I asked.
    – Dan
    Commented Jan 29, 2021 at 19:50
  • 2
    I have a hard time getting the testers to write more than "It's broken"
    – Ben
    Commented Jan 29, 2021 at 21:40
  • 1
    @DanielHatton I wouldn't say they are "lying." You're right it could be the way I'm explaining it or it could be a misunderstanding. Either way asking for a screenshot, and then using the same screenshot as a reference, I can make more precise instructions that they cannot say otherwise. If after that they still have issues, I would again ask for the same screenshots. I never had an issue where the OS or OS settings are at fault. It's 9 times out of 10 the users fault and that rare time when it's the software's fault, it's an easy fix.
    – Dan
    Commented Feb 1, 2021 at 19:45

The software has been extremely buggy, to the point of slowing down our productivity considerably. I am now bringing 10-15 hours of work home on weekends above previous amounts.

The first question I have is are you reporting this to the manager?

Is this at all reasonable that I should be expending so much effort to get serious bugs fixed?

Yes and no. Ultimately it comes down to money. As your employer is paying the money, the company has to assume that it is "working for everyone but you." If you're the only person experiencing the bugs, then yes, them asking for details may make sense for them ask you to try it out on a co-worker's computer to see if the bugs happen. Also cross browser support is tricky and sometimes changing browsers do help. It doesn't hurt to try it out cross browser just to verify as many times certain software will be made for one particular browser.

My thought is you should try the ticket's advice. Say you tried it across browsers, across co-workers, etc and it still doesn't work. I would also bring it up with your manager.

It's not very convincing, at least to me, to come to your manager and say, "I don't like it because they're trying to help me by asking questions." Instead you should state, "Boss, I am having a large amount of issues with this software. I am not able to do X, Y, and Z effectively and it is causing me to work 10-15 additional hours just to make up for the lost time in resolving these issues. I tried to contact the tech support but thus far, my issues are not being resolved. What can I do?"

I would also clarify to your manager that you're having to work weekends just to make up for the lost time you spent trying to resolve these issues. I want to say time is of importance here as well because the more time that goes, the less credibility you have. You already said you had this software for several months and you're only now bringing up the issues. I think you lose credibility when others are using the software to do their full work without losing time with bugs, and you're bringing it up months later. Your manager may reverse this and say that you have to resolve it because others are able to work and he/she hasn't heard of the same issue. You should bring it up as soon as you experience the issue and finding that the tech support is an endless back-and-forth and you're having to work 10-15 hours more. I would have brought it up the first time I uncovered the issue.

  • First question to ask: do you have a sufficiently up-to-date version of your Operating System? Commented Jan 28, 2021 at 16:09
  • I have specifically complained about software to my manager because "They're trying to help by asking me questions". In short, we bought some expensive software with a good support package, but everytime we ran into bugs and issues their support team would waste hours of my time with requests that I knew (and experience later showed) were completely pointless and unnecessary. Anyone who has called tech support and told "restart your computer" when you well knew it wouldn't help and they are just reading off a script knows how much of a problem that legitimately is Commented Jan 29, 2021 at 10:44
  • And while their support team needs a minimum amount of detail in order to make progress on these items, it sounds like they are basically handing off all their investigative work to the end-user, which is not a functional support strategy. Commented Jan 29, 2021 at 10:46
  • @ConorMancone On the other hand, having worked tech support, I have also been confronted with situations where I knew that restarting the computer would solve the problem, and convincing customers who thought that it was unnecessary was absolute hell (not to mention it increased resolution time, because you first had to exhaust troubleshooting other, less common, causes before you could convince them to try restarting anyway). Commented Jan 29, 2021 at 12:05
  • @MarkRotteveel I get that. However, given the long list of examples from the OP, I think it's safe to say that he's dealing with bad support. While there clearly are cases where tech support is stuck dealing with people who refuse to assist, there are also plenty of cases where tech support cause more problems then they solve because either they don't have enough technical knowledge or they don't care about wasting the customer's time. Commented Jan 29, 2021 at 13:37

Another developer's perspective here - this is symptomatic of a company with poor support systems.

The problem

When I'm developing, I can run the code line by line and see exactly what's going on. If there's an error I can usually see the exact path that was taken to get there. I can see the contents of the database, and for complex issues I can delete irrelevant data or create test data to help isolate the problem.

When I'm trying to track down a problem on a live system, I don't necessarily have the ability to do any of these things. I may not know your exact inputs, or the data it references. If I can make the same issue happen, I can debug it as above. If I don't understand the scenario well enough to recreate the problem we end up with "it works on my machine".

Back when I did support, I didn't even have access to the code. If I hadn't seen the problem before I had a few "hail Mary"s like rebooting, or starting from a clean document, but I'd have to pass the issue onto the developers, who were usually already working to a deadline to get the next version out.

The solution

First of all it sounds like you might be dealing with support department who aren't getting much help from their developers. Ask them if they can recreate the problem from the information you've given them so far.

Second, their developers need better tools. They should be asking you for log files, data exports, etc - things they've put into the system to record its internal state for them. The problem is that most companies don't see the value in these things until they've wasted a lot of time or lost an important customer. Putting in a new feature in order to win a new customer always has priority because it generates revenue.

What you should do

As the others have said, escalate this to your boss. Tell him that you can't continue to work unpaid overtime, and sooner or later your output will suffer. If the rest of your team is having similar problems, that's a big issue for him to take to his boss, or whoever is paying this provider.

Ideally there should be one person in your company with a list of all the issues and the power to change provider if things don't improve. That will cause the provider to devote some developer time to the problems rather than just hoping the support people can keep you quiet.

  • 1
    "As the others have said, escalate this to your boss. Tell him that you can't continue to work unpaid overtime". If she's an exempt employee, she will if she wants to keep the job.
    – RonJohn
    Commented Jan 29, 2021 at 16:04
  • 2
    Given the level of nonsense I suspect there's another layer at work: There's some disincentive to actually filing the bug reports, thus the support people are throwing up roadblocks to make the reports go away. Commented Jan 30, 2021 at 1:46

You mentioned that you are an educator. Don't forget about your most powerful resource. You have a multitude of fellow teachers who are all using the same software and are experiencing the same problems and bugs. Use that to your advantage.

Have your colleagues file bug reports on the same issues. Let them know what sort of screenshots and details to provide since most non-technical people don't have experience with that sort of thing. It's easy for the developer to ignore or downplay your ticket if they think it's user error or a system-specific issue. If they get independent reports of the same problem from 35 different people, all using different machines, then it's a lot harder to ignore. It also helps the developer understand just how many people this issue really impacts. Telling them it impacts the whole school is one thing. Getting bug reports from everyone in the school has considerably more impact. When bug reports start piling up that all come from email addresses from the same domain, management starts to worry that they could lose a customer if they don't get the problem addressed.

From a developer's point of view, it's frequently easier to investigate and fix a bug when it has been reported by multiple people. Everyone has a slightly different way of looking at or explaining things, and having multiple perspectives on a problem is useful.

Now if you weren't an educator, I think ColleenV's answer of escalating through management would be a more appropriate solution. Educators don't typically have that as an option, though, since the management structures are completely different than a corporate environment and IT departments tend not to have the same sort of escalation processes.

  • 3
    +1 for picking up on the education nuance. Software in this sector isn't like other software. People who haven't experienced education software before will read this and think something like "yeah yeah - I've seen bad software before" but you haven't, not like this. It's almost as if the person in charge of a country's education gave a lot of money to a friend of theirs who then hired some people who didn't know or care about software or education to write a system, and those people then sort-of half-wrote something and gave up, and the result is what everyone has to use for the next ten years
    – Aaron F
    Commented Jan 30, 2021 at 12:22
  • 1
    @AaronF - I've always said that for education software there are four groups: the developers, the people who select which programs to use, the technicians who support it, and the end-users who rely on it. These are completely separate groups that know almost nothing about the needs of the others, never consult with the others, and often have conflicting goals. There's a bit of that in the corporate world, but it's an order of magnitude worse in education.
    – bta
    Commented Jan 31, 2021 at 19:34
  • Should the OP who is already working overtime neglect his work and let it pile up even more to solve a problem that is not his to solve? He has done way more than his share by creating - as it sounds - excellent bug reports. If you have good contact with a developer, ask for feedback about your bug reports. If they agree, escalate to management. If you don't know a developer, also escalate to management. Commented Dec 13, 2021 at 7:31

TL;DR If the developer can't identify the issue then it doesn't matter how detailed the report is.

I'll explain how things happen in a development firm,

At least 1 of 2 things must happen in order to fix a bug,

  1. They must be able to figure out what's causing the issue from the description.
  2. They must be able to reproduce the issue (in development machine) from your description.

The chance of the point 1 happening is too low. If they can reproduce the issue then they won't be needing any more details.

Types of Issues

  1. Work flow errors - These can happen when the software is used differently from the way it's supposed to be. Almost always these can be fixed by the support team without involving developers.
  2. Reproducible errors - These will be fixed by the support team or developers depending on it's accessibility or complexity.
  3. Random errors - These are the worse error a developer can encounter, like "Once in a while when I click this it shows an error".

What is a support ticket?

Most of the time developers are not involved in supporting the customer. It's usually handled by a support team. They usually have a good knowledge about working of the software but less in actual development. Their main role is to identify the issue, fix it if possible or handover to developers in a reproducible way.

Support tickets are need to track the progress of an issue. It also help to identify similar or related issues and how long it took to resolve the issue. If the support team or developers are unable to reproduce the issue then it will come back to you for more details.

What I recommend,

  1. Try using Ctrl + F5 to clear cache and reload the webpage.
  2. Try clearing the local storage and cookies in browser and disable extensions. You may need to search for instructions on doing this.
  3. Try to recreate the issue in updated versions Google Chrome or Firefox. Using IE, Edge or outdated browsers are not recommend.
  4. Create a step by step instruction to recreate the issue with browser details. Write it as if you are giving this to a new joiner in your company. Don't give out passwords and other secure/private details.
  5. If the instructions are long or complex create a video recording. Always create a video if you are reopening an old ticket.
  6. If you think it may come back, send the instructions and video to a co-worker without explaining it to him in person. If he can recreate it, you are good to go.

The above instructions won't work if it's a random error. In that case you will just have to give them what they want.

Even after doing all this you still get request for details, then it may be a good time to talk to the manager of your development firm. Please note down the ticket numbers and have lots of “proof” before doing this.

  • 2
    Edge these days in recent releases is essentially a new layer of paint over the Chromium rendering engine. I use Edge as my daily driver at home because it fixes some small issues I have with Chrome.
    – Nzall
    Commented Jan 29, 2021 at 16:08
  • 1
    This is a good answer for someone who is struggling to write a clear bug report, but it sounds like the OP knows how to write a good bug report, so it isn't applicable to this question.
    – thelem
    Commented Jan 29, 2021 at 19:58
  • 1
    Random Errors: Every developers true worst nightmare. I once had a bug persist for 3 months that got reported by many users in all the normal details required including log files, detailed descriptions, etc. because it would just randomly stop working regardless of what you were doing. Turned out that session variables associated with being logged in were getting deleted by PHP's default garbage cleanup, but not actually logging you out; so, it was all unreproducible bugs. I suspect this is what the OP is really experiencing: not lots of bugs but 1 bug that happens in the worst possible way
    – Nosajimiki
    Commented Jan 30, 2021 at 20:31
  • @Nzall Edge is turning a new leaf. Hope it can keep up with Chrome.
    – lal
    Commented Feb 3, 2021 at 9:13
  • @thelem If the developer can't reproduce the issue then it doesn't matter how detailed the report is.
    – lal
    Commented Feb 3, 2021 at 9:20

You are filing tickets with a first line support team. Their role is to resolve customer's problems without bothering the expensive development team. They do not have access to make changes to the actual software (they can't fix bugs). Often they can be very effective in their support role - you'd be amazed how many calls these sorts of teams get that really are solved by turning the computer off and on again. They will also be familiar with errors that frequently occur in the application they are supporting, and how they can be fixed or worked around.

But sometimes there will be errors that they are unable to resolve, perhaps because there is a bug in the software that requires a code fix by a developer. At that point their role changes, and instead of fixing your problem, they need to clearly describe it in a way that someone else can fix it. They should be taking your description of the problem and repeating the steps on their own computer until they can see the problem too. They can then pass their description of the problem onto the developers, so they developers can change the software (fix the bug).

If they keep asking for more information, this could be because:

  1. The support team do not have the necessary experience to reproduce your issue and describe the bug to a developer, and they are not able to pass the tricky issues on to a more experienced member of staff.
  2. The issue is intermittent and hard to reproduce.
  • Given that the software is "extremely" buggy I think there's also a shout for 3. the company doesn't even have procedures in place to report bugs to the developers. So, never mind experience, the support team doesn't even have the right buttons. Commented Jan 29, 2021 at 22:58

When shipping software to a large number of users, especially non-technical ones, there is a dilemma:

  • Let the users communicate with developers - allowing less red tape and miscommunications, but at the price of a huge load of what are hand-holding/education support requests rather than bug reports; or
  • Let users only file support tickets, for handling by support staff - not developers. This means the developers will not be endlessly swamped with redundant, non-development-related support work.

There is definitely a lot to be said for option 2. Sometimes it's inescapable. What's important, though, is for this not to be a dichotomy: Having a mechanism for "promoting" lay users to those who can file actual bug reports and communicate directly with developers.

So, my suggestion is: Ask your manager to reach out to the software company, to ask them for a channel to the developers, on the promise that it will not be just sent out to everyone, but only for technically capable users who believe they have found proper bugs.

@ColleenV suggests, in the comments, that the situation you find yourself in is evidence that the software maker/supporter company is deficient, and is forcing your organization to pay for your time doing essentially QA work for them. So, perhaps it might be possible to replace them altogether. But I'm guessing that would mean a bunch of organizational politics and investment in retraining or what not.

  • 1
    @ColleenV The customer is already paying their employee to write support tickets that will be ignored. The suggestion is that the customer promises to write good support tickets, and in exchange the vendor allocated them to staff with the experience to resolve the problems, instead of the 1st line support team who have been proven to provide a poor service.
    – thelem
    Commented Jan 29, 2021 at 20:02
  • @thelem Why do we think the vendor who is unable to provide competent support staff will do any better providing a developer? It is unreasonable to expect your end customer to work this hard to resolve your bugs, unless they’re one of your only customers and they’re stuck with your software.
    – ColleenV
    Commented Jan 29, 2021 at 20:13
  • "Who is going to pay for the OP’s time collaborating with these developers to make software the company already paid for work properly?" <- I understand your frustration, but then - who is going to pay for OP wasting his time with interaction over support tickets? I realize you're bringing up the question of the adequacy of the software OP's organization bought, but that seems to be more levels above OP's head. I'll add a note about that though.
    – einpoklum
    Commented Jan 29, 2021 at 20:42
  • "Why do we think the vendor who is unable to provide competent support staff will do any better providing a developer?" <- Because experience teaches us that this is often the case. Technical competence and general life acumen and common sense often vary widely within a company. "They're stuck with your software" <- This is a very common case, I'm afraid.
    – einpoklum
    Commented Jan 29, 2021 at 20:45
  • @ColleenV: for that matter, why should a company using software that they are paying for dedicate staff to 10-15 hours of time per week lost to bugs? But that's what the questioner's employer is currently doing. So fact is they're in a mess. If there's a bug-free competitor they can switch to, sure, that'd be a good solution. But maybe there isn't. Commented Jan 29, 2021 at 22:53

TLDR: It's not unusual, but you should not accept this.

For a better result in bug solving from their part, you can :

  • Inform management
  • Quantify the time lost with every bug
  • Ask coworkers to report the same bugs.

In addition to all of these great answers, which already explain that this should not be acceptable, here are additional context & possible tips, assuming you can't (or won't) switch for another software provider.

Explain how much time you're losing with every bug, both in the bug report and to your management. It's not uncommon for a bug to be labelled as "not important". When you quantify it, it becomes more concrete.

Ask to be updated when your bug is being handled by a developper.

In big companies, bugs are treated by different teams, ranked by level. If a team can't handle the bug, it goes to the upper level. Team 1 is usually "call center": they filter all trivial bugs ("Check your internet connection", etc...). Team 2 knows the product specifications in depth. They can tell you if "it's not a bug, it's a feature", or that this workflow is not supported yet. Team 3 is the tech team, which can actually make changes to the code.

To be treated, the bug has to go all the way to Team 3. Problem is, Team 3 is rarely available, because there is always something else to do: other bugs, new features, a different product, ... A bug often lands in an endless backlog, and, if you're the only one to report it, will never be treated. It's also possible that teams 1 & 2, knowing the endless to-do list their tech team already have, try to never send the bug to them. Hence the endless requests.

Ask coworkers to file the same bugs.

They even can reference your bug ticket number, if they want to avoid all the scrutiny. The more people report a bug, the greater the chance for it to be resolved, or at least, prioritized.


Pretty much usual behavior for the first level tech support when there is (virtually) no next level one.

The product is abandoned.

No one intends to fix the bug.

There are no resources allocated to fixing any bug.

Their only strategy is to return the ball to the user as quickly as possible, in order not to fail their SLA.

They will play the same game with you until you give up. They are paid to do exactly this.

That's how the software is made (and supported!) by a corrupt public procurement process.

I am not sure how the cycle can be broken.

Depending on your workplace politics, the best strategy may be involving the management, your colleagues, your union or simply giving up.


The simple answer is, unfortunately this sort of total incompetence from software/testing teams ... is not unusual.

Unfortunately, you can only take it as it is.

An extreme response would be "Leave the company since they are the epitome of incompetence in support."

At the other extreme, shrug and ignore it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .