When do you NOT create a support ticket?
Posted by gkar_of_Narn@reddit | sysadmin | View on Reddit | 216 comments
I'm am currently in a "discussion" with a co-worker who insists "little things" don't need tickets. For me the biggest problem is not the concept itself, but rather where you draw the line. This morning, the phone system in one of our branch offices was down. Rather than creating a ticket, the person wrote a message in our chat tool. The issue for my co-worker is not the severity of the problem, but the time it took to resolve it. The SIP switch was rebooted and the problem was gone. Since the time from when the Admin saw the message to the time the phone was working agin was less then 5 minutes, my co-worker insists that there is no need to create a ticket.
This ingores the fact that the chat tool is not something people are required to have running all of the time (why, I cannot say) and it took over an hour for the admin to see it and Telephony has been defined as service and this particular outtages occurs often, so identifying it as a problem (a la Problem Management) is near impossible.
I support the philosophy of a former boss who said he would rather have 10 tickets too many over 1 ticket too few. I am curious as to what criteria others use to define what should be a ticket and what not.
TheGodThatFail3d@reddit
Always create a support ticket. No exceptions, if an engineer or technician is spending time on an issue, even if it's only 15 seconds, create a ticket
ultimatebob@reddit
Especially if it's something that caused an outage, so you can record the outage time. That way, if the phone system goes down again and some manager complains that "This damn phone system is always down", you have real downtime metrics to show otherwise.
jspears357@reddit
System outages should be identified by monitoring systems, not based on tickets
sin-eater82@reddit
"Even 15 seconds"... So create a ticket for creating a ticket?
That's the problem with the "everything that consumed time" litmus. There has to be more than "it consumed time".
MaTOntes@reddit
If it's an externally raised task. Yes.
If you are focused, and in the flow, working on a deeply technical issue and someone pops in to "fix" their mouse by turning it on, their 10 second fix has absolutely trashed your concentration on the original task.
Even if the work done to fix it is infinitesimally small. Chuck in 10-20 of those a day and your productivity is absolutely shot to hell. It matters. You have to log the small stuff too.
sin-eater82@reddit
Try reading my comment again. You totally missed jt.
MaTOntes@reddit
I read it, and so did everyone else. The issue is that you started with something that was either tongue in cheek or a smart alec remark. You then followed up with..
"Tongue in cheek" comments aren't taken too well when they come from a place of "UM AKCHOOALLY" based on an intentional misunderstanding. Followed up with a mansplaining criticism.
When u/TheGodThatFail3d made their comment everyone (except you) knew the unstated premise behind "if an engineer or technician is spending time on an issue, even if it's only 15 seconds, create a ticket"
vitaroignolo@reddit
"Wow everyone here must be an absolute mongoloid. I perchance to ascertain I may be the last soul of wit and lucidity on this internet forum"
Get over yourself. The range of people here goes from help desk to architects. Your shit attitude does nothing but stroke your own ego and detriment our profession.
I_turned_it_off@reddit
the time taken to raise the ticket is part of the ticket itself, as is the time taken to update documentation and monitoring systems after resolution of the issue.
That said, i know for a fact that I am far too lax in my own way of being helpful to users to follow this advice properly myself, but i do at least know where i am failing in this regards
sin-eater82@reddit
Thank you for not being a moron and actually getting what I clearly stated.
xVenlarsSx@reddit
If you do work that is not tracked in a ticket, work order or w/e, 2 things happen. 1. You do work for free, since it is not associated with anything traceable. People will get used to it, and come to expect you drop everything to solve a "quick thing" all the time, making support stats useless and removing visibility from your work. 2. Since there is no paper trail, there will be no way to source the issue and prevent it from happening in the future. If you always just reset the pw of a director on the fly, he will learn that he doesn't have to remember his credential since there is no consequence to his carelessness. A switch that need a quick reboot once will need it again in a week, and instead of finding why it's bricking, you're just shoveling it forward.
As other have said, you don't create the ticket, you answer the ticket. If they can be bothered to message you on the side, they can be bothered to open a ticket through proper channel.
If there is too much friction in the ticket system that people are avoiding it on a regular basis, your tickrt system need work.
You need to value your time more, since your user clearoy do not
Velvet_Samurai@reddit
I had a boss like this once. I only account for like 36 hours of my week the first few weeks after she hired in. She called me out on it in a staff meeting one week. "Why are you consistently only working 36 hours?"
"I work 40 hours every week."
"Then what were you doing those other 4 hours?"
"I don't know catching up, organizing my time, reading emails, sending emails, closing tickets."
"Ok, make a ticket for four hours once a week to factor in that time."
Demented_CEO@reddit
Personally, I'd consider everything that's not a si.ple setting toggle to be worthy of a ticket.
Our print server had an issue of "forgetting" the print queue if it wasn't restarted every now and then. That was the first thing IT tried when troubleshooting and voilà, problem solved.
Except, it kept happening from time to time. Only now, users had learned that restarting fixes it. Finally, someone from finance was fed up with it and demanded a more permanent solution.
The problem? The print server misbehaving has been like that "forever", but there's no paper trail to follow. Not even rough data on when or why it might lose the print queue. What gives?
When we were renewing our contracts, the issue of the print server came up with the CFO and IT's response that we haven't heard of any issues since that last reboot over a year ago.
Yes, that reboot someone from IT had done with no ticket or anything to follow up, after which users themselves took the liberty to reboot the print server. From IT's perspectice, all is good!
sin-eater82@reddit
For a CEO, you have poor reading comprehension skills. Try reading my comment again.
Of course log a ticket for the thing stou mentioned.
Demented_CEO@reddit
For a Redditor, you have even poorer reading comprehension skills. It's Demented CEO, dear sin eater.
UpstairsJelly@reddit
If the user base has the ability and access to reboot a production server, logging tickets is the least of your concerns for issue visibility
BrainWaveCC@reddit
No, there doesn't need to be more.
You cannot know when somerhing will go from being small to being hugely critical. You generate tickets for all work, or you will eventually lack critical visibility.
principalbean@reddit
If you support a user or touch a system it must be documented in a ticket. The ticketing system is the official record of events. If it isn’t recorder there it did not happen. Chat and email are for collaboration and communication. Not documentation.
LowMight3045@reddit
Didnt have to scroll far to find the correct answer . Seriously
ryalln@reddit
EVERYTHING. Then in the future you have proof of everything. The only time a client can’t lodge one is when there computer isn’t working and you lodge it for them.
idontknowlikeapuma@reddit
When i was doing help desk for a fortune 500 company, my director told me I wasn’t making enough tickets, that we needed the tickets to prove our worth.
So I wrote a script that would look for email notifications when Nagios (old network monitoring program) saw a connectivity issue, and would generate a ticket and close it.
Then I turned up the sensitivity on Nagios: any dropped packet generated an email, and in turn, a ticket. We just had to check the nagios folder on the mail server and clear it our. Soon, I automated that as well.
Tickets were never brought up again.
bobdobalina@reddit
Leadership just fired one of the maintenance managers here who's been quite productive but overwhelmed ... I was guessing because of lack of support by his juniors but not my department....
Leadership requested IT at an asset mgmt meeting and in the demo of the product they already use for preventive maintenance they opened the work related dashboard showing the entire management team and maintenance techs that the fired guy did 99% of the work.
Ok-Double-7982@reddit
He did 99% of the documented work.
That's why tickets are important though!
idontknowlikeapuma@reddit
Fuck middle management. I have only worked directly under the CEO for the last decade and don’t think I could handle not heading my department. And as a boss, I am cool as fuck.
I did learn a hard lesson, though, because I recommended hiring a person after I had a phone interview. Apparently, he never realized I was his boss.
He kept snapping at me because I was always telling him what to do and how to do things. Well, he was also ignoring me, was fucking up, and costing my department money.
In the firing meeting, after HR delivered the news, he asked if I was fired as well. HR explained that his manager should be present.
He looked at me and I could see him die inside. And I don’t get it: the CEO introduced me by my full name before putting me on the phone for the interview.
So now, I walk a fine line of not seeming like I am on a power trip, but making it clear that I am your damn boss. Really felt bad that he just, for whatever reason, couldn’t piece that part together.
But he was pretty toxic and was costing us money, but had he just listened…
bobdobalina@reddit
I wish my mgr, VP of IT, knew a damn thing about IT....to be fair he is a great manager but absolutely not technical at all. I've been basically under the CFO for 20 years when he retired they put this guy over me...
idontknowlikeapuma@reddit
Dude, every CTO I have seen, outside of myself, is really just an accountant, save for one. And that dip shit replaced ALL the networking equipment with Cisco equipment, for the sole reason that's the only equipment had experience with.
For no other reason. And when there were network disruptions, guess who got the blame? Not that jackass. We were expected to work throughout the normal business day and then swap out and test equipment throughout the night. Obviously, there will be hiccups.
Don't "fix" what was never broken when you have a team who knows the network inside and out. Just a waste of money and a cause of stress.
Guess what? The entire team, for a nationwide company, all quit halfway through his "upgrade". And we all gave the same reason.
That dude didn't last. They ended up outsourcing to a MSP, because they couldn't fill the hole fast enough. Stock fucking tanked.
wbqqq@reddit
This. There are 4 purposes (at least) for having a ticket - to communicate/notify that the issue exists - to track/show work that is being done and that is to be done -to record that something happened and potentially be a resource for resolution if it happens again - to provide metrics to justify the size of the support team.
heisenbugtastic@reddit
I agree, but I have pinged and called during production outage while writing a ticket... Yeah it's go boom, all hands on the call.
angrydeuce@reddit
This, everything. If I spend more than 15 seconds talking to someone about it, ticket.
Thats how we track what departments are not training their people and trying to get helpdesk to do it for them. When I meet with the Cs and go over these hours once a quarter, we look at those figures and thats the only way that we can find those sorts of internal deficiencies with department heads and similar.
Every communication also goes through the ticket system. No direct emails unless it is also replicated in the ticket system (for example when tagging in outside vendors). Everything in writing. You can tell us all day so and so isn't getting back to you but if I dont see that in the ticket, I cant prove it.
Ticket or it didnt happen.
MakeAmericaPoopAgain@reddit
Everything?
deep breath
EV-ER-Y-THING! 👏
melkemind@reddit
I tell people that I check my open tickets at the beginning and end of each day to see if I have any outstanding work, so they are guaranteed not to be forgotten. If they just send me a chat or an email, it might get buried and lost forever with no way for me to track it. That's not me being difficult. That's just the reality.
the_syco@reddit
Everything is a ticket. Especially the easy fixes, as it helps boost your stats. Heck, have a copy & pasta template from notepad for the easy ones.
josephowens42@reddit
No ticket, no work!
ghostnodesec@reddit
while I do lean towards if it takes longer to log the ticket then it does to do the work, things like outages, rebooting, need for audit trails (acct perms) stuff like that, log the ticket. One way mgmt can fix is routinely show how many tickets each sysadmin closes, suddenly you'll have tickets for everything, especially if performance bonus is tied to it
Acct4SrsBsns@reddit
"When a measure becomes a target, it ceases to be a good measure".
DueBreadfruit2638@reddit
Everything. The little extra time it takes to log a ticket for a simple issue pays dividends later if you need to justify a solution for a recurring problem. Or worse, if you're confronted with layoff demands from upper management, having the data to quantify your team's workload can potentially save someone's job.
Trust_8067@reddit
Everything needs a ticket. Of course, If it's going to take 10 seconds and my friend in another department can do it right now, I'm going to ping him. If he wants a ticket after the fact, I'll create it, if he doesn't ask, less paper work for me.
SamuelVimesTrained@reddit
Technically : anything that requires any action from me > ticket.
Otherwise management might think we`re not needed.
How do I sell this to users:
- if you don`t enter a ticket, we cannot track issues, and cannot use these outages to request new equipment/software.
- if you don`t enter a ticket, and only send a teams message, i may see it too late, or not at all.
- no ticket - no service.
splendidfd@reddit
Those are all good reasons to have tickets lodged but why does the user have to put the ticket in?
gkar_of_Narn@reddit (OP)
How do I sell this to users:...
I like that!
Sure-Passion2224@reddit
I used to work with a support team that maintained a troubleshooting wiki. The final stage of a ticket was to review and update the wiki. More importantly, the first stage of working a ticket is to review the wiki for known solutions. The wiki is readable for all network users.
q123459@reddit
there should be simplified path for making such descriptive-only tickets, they are important for problem traceability - how often same problem reoccurs. this measurement then could be used to try to reduce amount of specific task reocurrence for example by transitioning it directly to l1 support.
if it's an one off rare issue with systems (not user support) then it's 2x as important because it helps to maintain error log(discoverability) of this specific system
so use voice input to text to quickly create descriptive ticket when issue is fixed, and every one such ticket must be blameless (administrator fixing that ticket should not be held accountable if it reoccures).
if your ticketing system cant do that - use some knowledge base for those short tickets
RunningAtTheMouth@reddit
It's easy. Send an email. Okay, now instead of sending it to me, send it to helpdesk. The only exception is when you cannot log in (such as a locked user account, or the computer won't turn on.) Even then, I get a ticket.
Why? Records. How many times has Bobby had a locked account in the past year? I'll know, because it's in the helpdesk. How often do we fix a particular printer? I'll know because its in the helpdesk.
I don't care how simple it is. If they want my help, it goes in the helpdesk.
Tell me as I'm walking through the shop? Great. Now send that email, because I WILL forget by the time I get back.
The ticket requirement is NOT unreasonable. Just put in the doggone ticket.
Overdraft4706@reddit
If it takes the user longer to make the ticket, than it is for me to fix the problem. I just tell them not to bother. Our ticket logging process is not that smooth, so i would prefer to have them owe me one in the future.
mjung79@reddit
Does your accounting department have to issue invoices and credit memos for bills under $50 or do they just send and receive cash? Does your HR department take employee harassment complaints without an official report if they take less than 5 minutes to discuss? Does your janitorial staff just spritz some air freshener if things look pretty clean?
Poetspen@reddit
Your coworker is wrong in every possible way. I’ll flip a ticket for answering a question.
MDParagon@reddit
It's Miranda rights for me, it's for everyone's protection/documentation
djelsdragon333@reddit
We have a "5 minute rule" for desktop support. If you see us in the hall and it takes us less than 5 minutes to troubleshoot, we ask that you create a ticket, but we'll generally let it slide if there's no ticket. Anything more than 5, we stop support and have them submit a ticket, which is then reprioritized.
The general understanding is that if you see us on-site, we are working someone else's ticket. They get help because they followed the process. Do not ask for 5 minutes if my arms are full. I am not available.
spacecadetdani@reddit
Make a ticket whenever a task or research takes more than 5 minutes. This beefs up numbers.
PixelSpy@reddit
Emergency situations are our only exception. If your computer is on fire, your account got compromised, you're unable to use your computer at all, etc.
Our boss has told us to ignore teams messages of users who think they're special.
RedditDon3@reddit
When they do that to me, I either forward the convo to the ticketing system or create one myself and add the info. Everything needs to be tracked, not for how long it takes but for trend analysis, etc.
Sukosuna@reddit
For me the line is when a problem is not related to any systemic error and the user is only looking for guidance. I agree that most things should be a ticket when it involves some kind of intervention to rectify it for documentation. But when Sally from Sales sends a message saying her password isn’t working “evn tho the same number are work on the login screen” it’s more time efficient for me to remind her there that PINs and passwords are different, and if she needs it reset, that’s when the ticket submission becomes necessary.
jeffrey_f@reddit
Actually, it is in your best interest to create one since it shows history of that person. Also is ammo if they say you aren't busy
fragwhistle@reddit
Echoing what others are saying. An issue didn't happen if there's no ticket/job for it.
How the ticket gets created and managed is a different story though.
I'm not a stickler for making the user submit a ticket as the initial report of when an issue happens. If someone comes and finds me to tell me there's an issue then I'll create a ticket for them. If they send me a chat message, a personal email, an SMS, phone call, carrier pigeon (you get the idea) then I'll pop a ticket in for them.
What happens after that is a different story. Regardless of how the issue gets reported then it needs to go through a process of triage and prioritisation before it gets worked on. If it's reported over the phone or in peson, triage happens immediately. If it's email, sms, teams etc then it'll happen in a reasonable time. We're still working on what that time is and how people will be told.
We do communicate that issues should be reported through the official phone support phone number and email address as there's processes in place for managing availability and on-call. If someone sends something directly to a person they'll get some pretty blunt messaging that it's been forwarded to the support system and that future issues need to be reported through proper channels.
For a bit of context I work in not-for-profit broadcasting so sometimes running up to a tech and saying "we're off air" is the right way to report a problem.
Morgund@reddit
There is no such thing as a time to not create a support ticket. Remember: if it's not documented, it didn't happen. Every issue should be tracked with proper issue tagging. Every ticket should have an accurate description of the issue as presented by the customer, concise detail of troubleshooting and findings, and detailed steps taken to resolve.
If you don't have time to create a ticket when you're informed about an issue, take notes that you can refer back to when creating the ticket later.
Be sure to use timestamps in your notes to track TTR and when things happened or were discovered.
LuckHart02@reddit
yeah creating tickets for every little thing is the absolute worst but management always wants the metrics. we basically just gave up trying to force people into the portal and threw Siit.io into our slack instead. when users start sending their internal tool requests it just grabs the thread and turns requests into tickets automatically in the background. honestly it just saves us from having to manually document every single quick fix.
AntagonizedDane@reddit
No ticket, no issue. I've seen so many non-issues just disappear, like mist before the sun, because people couldn't be bothered spending 30 seconds creating a ticket.
NerdsTookAllTheNames@reddit
Also: no ticket, no work. Even working in an internal IT department, I have to fill out a time sheet every day. The time spent on issues gets charged back to other departments. It rarely happens, but if a department asks what they're being charged for, I better have the ticket numbers.
Civil_Inspection579@reddit
yeah this is less about severity and more about visibility and tracking
if it affects a service or could repeat, it should probably be a ticket
chat messages get lost and don’t help with long term patterns
i’d lean toward over-logging rather than missing issues
Chaise91@reddit
Visibility and tracking is great if your ITSM tool isnt terrible. We use some god awful ServiceNow build that is completely incomprehensible. Ive tried and tried to build reports of my teams tickets but it never works. No matter what angle I approach it from it just doesn't work. Therefore, I'm fine if someone just sends me a message on Teams. As crazy as it is, Teams is a better ticket management tool than ServiceNever. Our org is too big and too invested in it to care, so I and many other admins around the world just scream into the void.
sr71oni@reddit
A great question to ask is “how many times has the phone service went down in the past X months?”
BooleanOverflow@reddit
Tickets aren't that reliable either. A lot of downtime goes undocumented and if it gets noticed, there might be between 1 and 1k tickets for one incident.
sr71oni@reddit
It’s at least a good place to start for metrics.
“Department reported that the phone system went down 11 times within the last three weeks.”
Is a lot better than relying on techs saying “oh yeah I got a few chats about it over the past week” and having to cross reference it with other techs that may also have worked on it.
How a ticket is handled and the downtime associated with that is more in the SLA definitions, so a management issue.
waxwayne@reddit
Why are customers responsible for tracking your work? Why can’t you track your work like every other customer service department in a company. It’s especially frustrating during an emergency situation when systems are down.
PictureFamiliar1267@reddit
How does an engineer or help desk opening a ticket force the customer to track the work? The person you replied to didn’t say anything about forcing end users to open a ticket
CyberPhysicalSec@reddit
In my old place, we had to create multiple tickets even if it was a similar job. I.e change SSD and RAM would be 2 tickets.
CyberPhysicalSec@reddit
No ticket, no work. It’s a performance metric.
Glad_Cauliflower2490@reddit
Audit is important, but also having the data to know when behavioural changes are needed is good. Having the data to prove something is happening is powerful. Then showing why solving it saves time in the future can be justified.
lifesoxks@reddit
We have several way to contact helpdesk\it:
A Ticketing system.
A WhatsApp group for production-halting problems that includes IT, maintenance, infrastructure and management where only certain people can raise problems that require immediate intervention, and each occurrence is then logged and ticketed with screenshot.
Email, we just cc a dedicated svc account that auto creates the ticket.
Phone call, if for some reason you can't access your computer, but we still require the ticket afterward (say user linked out\forgotten password\computer is fucked somehow)
Darkone539@reddit
Where i work there are things that don't need tickets. Such as a mouse being handed out because the company (public sector) had always written it off as a consumable.
I don't agree with that, but it's not my call.
a60v@reddit
The labor cost to deal with that ticket almost certainly exceeds the value of the mouse. Making a ticket is counterproductive.
gkar_of_Narn@reddit (OP)
We're going to implement the Web shop that comes with the ticket system, so tickets are created that way.
volster@reddit
In theory absolutely everything should get a ticket even if only to record that they called
In practice - I dump the entire conversation and my stream of consciousness straight into the notes while still on the phone..... so if it's sufficiently trivial that I can answer the question or they figure out they'd yanked the power cord before the pate loads I don't bother and it's onto the next one 🤷♂️
Hyperion_Silenus@reddit
I told everyone that I'm getting paid on their company's dime. Everything I do is ticketable. Me going to toilet, ticket! Chat with someone for 2 min about laptop, ticket! Farted, ticket!
0verstim@reddit
If you dont put in a ticket, the next person won't be able to look and see what the fix was. You also cant track metrics and show your bosses how often this happens, to justify upgrades.
BamaTony64@reddit
what I was supporting end users my very first question was "what's the ticket number?" If they didn't have one, I asked them to call back with a ticket number.
SpellConnect8675@reddit
It’s annoying sometimes but yeah everything should get a ticket.
RossiFan46@reddit
User emails or messages you on Teams that they locked their account. You unlock it with out a ticket and go about with the rest of your day.
Or
You take that request, log a ticket just for a paper trail. That user's manager sees that a ticket was open and calls you saying "That is strange, that employee is away on vacation. Why would he need his account unlocked?"
Disorderly_Chaos@reddit
I wrote a simple script that puts a ticket into my system for any little thing. Because * my memory is shit * I might need to CYA later * The boss man might suddenly decide to change the metrics of what constitutes good job performance.
a1b2c3d45ef6@reddit
If you expect my help, my expertise, or me to do something. Nothing gets done without a ticket.
bit0n@reddit
My logic was if it takes longer to write a ticket than to fix it I won’t bother. Boss said I’m stealing data as I could fix 100 little issues that would show a bigger problem if they were all logged. So now everything is logged.
gkar_of_Narn@reddit (OP)
Server crashes and restarting takes 60 seconds. A service was down for 20 minutes, writing a ticket to document the crash and the cleanup takes 10 minutes. Sill no ticket? For me, it's not purely an issue of time.
bit0n@reddit
More user calls as everything is printing in A3. Jump on change it and hang up in 2 minutes? We might be doing that 50 times between different techs till someone mentions it and we all say I have done that x times. It’s then very clear the print server is the issue.
If 5 people had logged it the system would have flagged it as a problem for a Team Leader to review.
TheEvilAdmin@reddit
Everything. No matter how small.
User: "Can you change my desktop Wallpaper?"
Me: "Create a ticket"
marklein@reddit
In addition to resolution time, we also consider scope (number of affected users or systems) and severity (work or service impact). If any single of those three metrics is above zero then it gets a ticket. Using your example, the time was \~zero, but the scope was an entire branch office and the severity was high. That definitely warrants a ticket.
How else can you tell that the branch office switch needs replacing if it doesn't get logged that it's down weekly/monthly?
TheThirdHippo@reddit
Everything goes in a ticket. If it keeps happening and there’s no record, you miss the problem. Even if it takes longer to raise and close the ticket, it doesn’t matter, the issue needs to be recorded
shepdog_220@reddit
For an issue like that 100% a ticket.
If Debra in accounting walks up to my desk and can’t sign in and I find out her account was locked out or was putting her password in wrong or needed batteries for their mouse or something? Yeah I won’t put in a ticket.
Which I don’t think we should be the ultimate decision makers when it comes to what should be a ticket and what shouldn’t be, that’s a dangerous game to play but I do it.
Palmovnik@reddit
How do you want to document if outage like this happens regularly if it is only chat?
Every single thing, even changing job description a typo in their name or even changing non working power cable needs a ticket.
Expensive_Finger_973@reddit
Should everything besides your lunch and bathroom breaks have a ticket? Yes.
Do I always follow the above rule? No
AegorBlake@reddit
Ticket numbers can help you get a budget increase so everything. Also a major thing in IT is having paper trails.
BoltActionRifleman@reddit
We have people who will call the IT number, which rings to all of us, and when no one picks up they’ll then call each of us individually. To top it off some some will even leave voicemails. This is sometimes followed by choosing a chat platform to send each of us an individual message “Hey, Bob’s not answering his phone and neither is Ron, can you help me?”. All of this effort expended when all they have to do is create a ticket, which takes maybe 30 seconds to a minute. At this point, I’m beginning to think these types of people aren’t ignorant, malicious or rebellious, they’re just plain dumb.
GezusK@reddit
Do they expect the user to judge what needs a ticket and what doesn't?
megaladon44@reddit
when you want zero pressure and for the issue to be resolved in your own time on the down low.
sleepmaster91@reddit
We recently switched to connectwise manage and one of the first philosophy is "everything is a ticket" even meetings
illankid@reddit
When its a refferal
Expensive_Plant_9530@reddit
Anything that takes more than 30 seconds, should be a support ticket. If I’m walking past someone’s desk and they asked me oh how do I change my default printer? That doesn’t need to be a support ticket.
But yes, even small things need support tickets. If you don’t track the small things, they often turn into bigger things because no one has any idea of how often these problems have reoccurred, makes you unable to track trends, etc.
In our IT department, we sort of have a little bit of an issue with IT technicians, not creating tickets when someone calls over the phone and resolve the issue over the phone in the same instance.
I try to drive it into their brains, if they call and they have yet to create a ticket, you’re doing it for them over the phone right now. Before you even work on the issue.
Pristine_Curve@reddit
A formal process ensures that everyone is seen, no one cuts the line, work is tracked, and reoccurring problems are visible.
There is no criteria where a service down for an entire site wouldn't be a ticket, and chat apps aren't a reporting method. This is one of those common anti-patterns which develop in the absence of a line being drawn. I encourage you to draw that line. Anyone who tries to go around the process receives the following:
"For IT help, file a ticket via or call the helpdesk at #. Issues submitted by texting, chatting, emailing directly will not be worked."
Don't try to negotiate or convince people to agree regarding this, because it's not really a discussion for them. They will simply come up with a never ending series of rationalizations why they shouldn't have to participate in the process.
"This is the way it is."
But it's a minor issue!
"When you want IT to spend time on it, file a ticket."
xb4r7x@reddit
Everything needs a ticket. When management comes a knocking wondering what work is getting done, being able to show them a log of all the shit you do is going to be a lot better than trying to remember all the little shit.
Jmkott@reddit
For us, this would definitely require a ticket. We can’t just reboot a device without a ticket and approval.
Having a ticket also helps with “this thing has been crashing by every week for months” but no one has ever logged a ticket so the underlying cause never actually gets fixed.
PDQ_Brockstar@reddit
I used to be firmly in your co-workers camp. I didn’t want to be the guy nagging people for tickets for something I fixed in 30 seconds. But I’ve seen too many issues arise, and some pretty serious “what would you say you do here” situations, that could have been resolved easily with documented tickets.
gunsandsilver@reddit
Do you have a ticket for this question? I can’t answer until you provide a ticket #.
MoistMe@reddit
Documentation, enough said
gkar_of_Narn@reddit (OP)
Are you saying the ticket is "documentation" or "documenation" does not require a ticket.
MoistMe@reddit
Submitting a ticket for anything is a good form of documentation and reference. I look up old tickets all the time whether it was because I remember or heard the specific issue happening in the past, or it was some one off a tech who is longer here worked on, or a higher up asks about it etc.
VNDMG@reddit
Everything. Our efforts are invisible enough. We need to always be able to prove our workload and demand. Especially when trying to get more headcount for the team.
badaz06@reddit
I'm more like your co-worker. If I spend more time opening and closing a ticket than actually fixing the issue, I'll normally not create a ticket. IMHO the ticketing system where I am is clunky and a PITA, full of drop downs that typically don't have the item I need or is categorized in under a different menu system with no flexibility...for example if I may tweak an email setting for someone in Purview DLP, is that under Purview, Email or 365? And to figure out which I spent a ton of time searching.
If someone sits in front of the ticketing system 8 hours a day they can probably zip it out PDQ, but that aint me :)
steveatari@reddit
Obnoxious levels of tickets is annoying if they are literal non issues or multiple tickets for exact same issue. That flooding made it frustrating but not creating tickets is worse as you're tracking less, don't remember when something occurred exactly or precisely what the fix was last time it happened. Also, paper trail if it becomes more serious down the line. It can be helpful to display patterns in either staff, tech or clients.
You could start to define criteria where tickets are recommended vs not and even examples if so inclined.
Aegisnir@reddit
I think the big question here is how long does it take to make a ticket? Is it a 10 second thing or is it a long drawn out manual process? If the creation process is super fast and not cumbersome, everything should be a ticket. If it takes 5 minutes to make a ticket, I can understand the friction point.
Sideshow-Bob-Ross@reddit
Generally if the fix takes less time than making a ticket, then I don't make one.
Bagel-luigi@reddit
If an end user out in the business asks for some advice but I don't have to check or edit/amend anything myself then I won't bother with a ticket.
If they want me to actually change something for them, or grant myself access to screen share and show them how to do something, then I'll want a ticket for it.
gkar_of_Narn@reddit (OP)
What if that "advice" take 30 minutes?
Bagel-luigi@reddit
Then yes, I'd like a ticket.
bobdobalina@reddit
If it's so quick then open and close a ticket after...everyone is happy.
ReptilianLaserbeam@reddit
It's not what you believe or feel. Is a service interrupted or stopped? That's an incident, you need a ticket, period.
spyingwind@reddit
The ticketing system is my memory. If there isn't a ticket, even for the small stuff, then I will forget.
I'm even good with just a title like: "Need N software installed". That's good enough. I can schedule it. The ticketing system already has your info, or who put in the request.
Some companies I've worked for in the past would use the ticketing system as the time log system. We put in our time into the tickets and that is what was billed to the customer. If it wasn't a ticket, it didn't get billed.
genxer@reddit
Almost everything should be a ticket. Our director (my boss's boss) has never entered a ticket.
I'm not going to win an argument to make him do it. He is the exception that proves the rule, though.
gkar_of_Narn@reddit (OP)
IMO, anyone at the level of the IT department head or higher gets a free pass. I even do it for the "assistent to the CEO". She can be a pain, but it's because she's doing her job and is great at it. Plus I don't want her on my bad side.
genxer@reddit
Oh the organizational director (I'm the head of IT aka the "IT Manager" ). Agreed, I pick my battles and, if it needs a ticket, I put in a ticket for him.
compmanio36@reddit
The only time I don't create a ticket, or ask the requester to do so, is when no action is required of me. Just asking a question? Fine. That's just an email/Teams message. Asking me to take action? Ticket time. It not only tracks your work for later retrieval, it shows management how busy you are. Without tickets, you can't prove your need for headcount, that you're working as much as you are, etc. You always need to be able to point at real numbers to show what you do at your job. Don't shortchange your future self when management comes knocking for proof that you're busy or need more people on your team.
ride_whenever@reddit
This is not a no-support ticket problem, it’s a poor ticket tooling problem.
Give the people a way to generate tickets from chat, they’ll use it, assuming it also gets them a prompt response
loupgarou21@reddit
oh man, everything should be a ticket. I think this is probably a misunderstanding by your co-worker on what the point of tickets is. Tickets aren't just there as a task list of issues that need to be resolved, they're also there to track workload and performance for your team, and are instrumental in justifying hiring decisions.
Seriously, having something the IT supervisor can point at and say something like "70% of our available time is being documented in tickets, that doesn't include things like meetings, and we're needing to place these improvements that you're asking for on the backburner because we don't currently have enough capacity to accomplish those tasks" is invaluable when it comes to asking for budget to hire another employee or buy additional tooling.
gkar_of_Narn@reddit (OP)
"Tickets aren't just there as a task list of issues that need to be resolved, they're also there to track workload and performance for your team, and are instrumental in justifying hiring decisions."
Bingo!
slashinhobo1@reddit
I create support tickets for everything. Even if i need another person in it to do work. Not only does it show they are doing work but it keeps them honest and on top of doing it.
I hate when people come up to you looking for you to do something while in the middle of something else. You forget and they come back did you do it yet?
gkar_of_Narn@reddit (OP)
I'll forget to look at the ticket I just created.
WizardsOfXanthus@reddit
EVERYTHING gets a ticket. Even if you get the proverbial shoulder tap that there is an issue and want to fix it, I always tell the person to please submit a ticket while I investigate. Even if I fixed it before they created the ticket, I still follow-up telling them they need to create one to account for my work efforts. Regardless, you want history of these issues documented, and that's another reason for the tickets...archival purposes.
If they still don't create one, I remind them again, but CC their manager and my manager on it at that point. Rarely happens, but seems to do the trick.
gkar_of_Narn@reddit (OP)
If they still don't create one, I remind them again, but CC their manager and my manager on it at that point.
I like that!
ThelTGuy@reddit
I used to just do the work especially if it's admin work, problem is a lot of my day is not tracked at that point. Boss asks what I do all day and I don't have logs to back up what i do. So I found a decent compromise "weekly admin ticket" is a weekly ticket made every Wednesday, placed on hold upon opening to not kill SLAs and any small things go there. Next week I was top of the team in logged hours worked.
gkar_of_Narn@reddit (OP)
I like that apporach. I'm not sure how it would work in my envirtonment, but I still like it.
SkippySparky@reddit
My rule is: If you need IT to do something, you need a ticket.
Capta-nomen-usoris@reddit
Maybe in three months and every three months after that system fails. Would be nice to have some record of it when someone is searching for it in your ticketing system. Your coworker should be educated.
gkar_of_Narn@reddit (OP)
"Your coworker should be educated."
I almost wet myself. Yes, he does. He's one of those IT-guys where it is all "T" and absolutely no "I". The answer is always to throw more technology at a problem until you can no longer see it as a problem. Sadly, he's one of the team leads.
Mindestiny@reddit
The line is when it becomes a request to provide work. Work = a ticket.
Someone just asking a question? "Hey do we have a software that does X?" Not a ticket. As soon as it moves to "cool, can I have a license for it?" Now it's a request that triggers work behind done = ticket.
brispower@reddit
If it's a quick one do the work and make the ticket for the user yourself, it gets logged, user is happy everyone wins.
If it's a big deal just make the ticket and say, made a ticket for you, will get to it asap.
Helpimstuckinreddit@reddit
Yeah in the real world if a critical system goes down you aren't gonna get away with "I'm not looking at this until you create a ticket".
Messaging works well for quickly bringing attention to it.
Then best case you go "looking into this now, please create a ticket in the meantime for record keeping".
Ideally they do but if not, you create one afterwards and remind them that it's still important to create a ticket after messaging about it.
Visible_Spare2251@reddit
yeah, exactly this. I'm totally fine with someone dropping me a message if they notice the phones are down and its urgent.
We can also create a ticket from a message in 2 clicks so its no big deal
gkar_of_Narn@reddit (OP)
What are you using for your messaging? Do you mean forwarding an email?
Visible_Spare2251@reddit
Slack
chrisgore-spor@reddit
Create a learning centre. This can be done for internal and external purposes. For internal use, our learning centre holds all of our SOP's. Want to know how to submit leave? Our learning centre has an article on it
For external purposes, the learning centre is an ever evolving repository of articles that are written in line with the most common tickets that get raised to our help desk. First port of call for a client is to raise a ticket (which they do within the learning centre). We have then set it up in such a way that an article related to the ticket gets sent to the client for quickly rectifying the issue. Only after that, if the issue is not solved does the ticket get escalated to tier 2 and our engineers take it from there.
Since we incorporated this, we have had huge success with ticket rectification because like you say, quick faults are solved easily and quickly.
For ref, you can see our learning centre here - https://service.spor-group.com/sportal
gkar_of_Narn@reddit (OP)
I checked out the learning center. Looks good. Are the lists of articles created manually or is there some automatic mechanism like posting the most frequently used articles.
When we implemented KM, I am going to modify the tickets forms with a button that creates a draft article based on the ticket.
chrisgore-spor@reddit
It’s worth noting too. That on the home page of our website, we have a chat bot function. That function takes its answers from the articles that we create on our knowledge base
chrisgore-spor@reddit
Our service team manually create the articles and publish. They work with our clients on common issues and tickets that are raised and then write an article to address the issues. That article then acts as a constant resource every time one of our clients raises an issue meaning the help desk team don’t have the answer the same question over and over again.
gkar_of_Narn@reddit (OP)
We have a wiki, or better to say it's an unplanned, unorganized collection of articles. Knoweldge Management is on the list for the next phase. AMong others we're migrating the Wiki to KM module in the new ticket system.
niamh-k@reddit
It wasn't worth raising a ticket because it was less than 5 minutes? How do you do problem trend analysis if you have no way of tracking the problem? If I'm a newbie in your org and this happens when that colleague was on leave, how do I know that was the fix if it wasn't documented in a ticket?
Everything needs a ticket. Not only for me to record my time against, but also so that we've got a record of exactly what's been happening and what the fixes were.
Sure, it might take longer to log the ticket than it took to fix it, but that's not the point.
98PercentChimp@reddit
We have Jira integrated into Teams so it’s simple to turn a message into a ticket. If a coworker who I get along with or a C Suite asks me to help with something small, I usually won’t bother with a ticket. We aren’t too dependent on KPIs.
However, the correct answer is a ticket every time for everything for everyone. Especially for larger orgs.
Japjer@reddit
Everything.
How are you supposed to identify recurring issues if you don't document those issues?
wanderinggoat@reddit
we had one guy who insisted that Microsoft Word had to have its menus changed , specifically two menu items. Each month he would try to log a job for it and we would explain that it was not going to happen. It would not get logged because a lot of time would be wasted investigating this and eventually even in the unlikely situation it was escalated we were sure it was not going to happen.
gkar_of_Narn@reddit (OP)
Yes! Tracking bogus requests.
Vindalfur@reddit
When those "little things" become your whole work day, then what?
I'm currently working in a place where tickets are almost nonexistent, small IT department, blue collar workers who almost always just phone you or talk to you on the hallway. It's draining.
Inanimate_CarbonR0d@reddit
Same boat (blue collar, small IT team). But I love it!
Meadbreath@reddit
Hey, thanks for making me comment for me. Almost the exact same scenario here.
TechinBellevue@reddit
Everything - it is how you justify your time, discover patterns that can point to big issues coming down the pike, justify IT purchases, etc.
Velvet_Samurai@reddit
This fundamentally misunderstands the point of the ticket system. Here is my biggest pet peeve. I get a ticket, "My computer won't turn on." I get up from my desk and start walking out to that person's desk. Halfway there, someone sees me and goes, "Hey, I can't open Excel. Can you take a look?"
"No, I'm on my way to Steve's desk, create a ticket."
"But you're right here, I really need in Excel."
"I'm not right here, I'm in transit to Steve's desk."
If everyone would just create the ticket I would get to them in order, but someone refusing to create a ticket is just another way of saying "I want to cut in line in front of my coworkers."
It's never ok.
Flaky-Gear-1370@reddit
One of the best features in Zendesk (others have the same) is you just forward their email or chat to service desks email and it’ll create a ticket in their name and if youre fancy you have ai doing your ticker classifications. Then it’s literally a two second job to close them
gkar_of_Narn@reddit (OP)
I checked and the tool we use could be configured to send email from a channel/stream. I am goping to look into that more. Thanks for the idea.
MadForestSynesthesia@reddit
Which ai does this? It interfaces with zendesk you say?
GloomySwitch6297@reddit
in 3 years time your manager may ask you: how many times the phones went down. can you provide me a report with dates and times.
good luck going through your memory... good luck!
Solkre@reddit
Yes - myreport.gif
waxzR@reddit
Everything should be a ticket, unless you care so little about the requests that them being forgotten doesn‘t matter to you at which point why even ask
gkar_of_Narn@reddit (OP)
"unless you care so little"
Interesting...
christurnbull@reddit
When I'm at fault
Zablonski@reddit
Once your system is in an abnormal state, you are automatically into incident management.
If your user isn't reporting a service ticket as the initiating event, then you need to be creating one throwing them under the bus "user X reports system down..."
Since postmortem and RCA is automatic after an incident, you drag them (the recalcitrant user) into the mandatory postmortem meeting and create action items as a result of your 5 whys that show up the systemic failures of non-reporting of incidents.
This now becomes a governance / HR / training issue that is pushed to line managers to enforce, and now you have users creating tickets.
gkar_of_Narn@reddit (OP)
one throwing them under the bus "user X reports system down..."
Love it! Our ticket system allows you to differential between the person reporting and the person affected., but that little extra "jab" is nice.
"By the way, Mr. Other-Department-Head, please talk to Joe about never creating tickets and always calling random people."
cbass377@reddit
If user tells me about a problem they are having, while I am getting coffee in the breakroom as an example, I give user a list of things to try verbally, user tries them, and it fixes the problem. Then no ticket required.
So basically, a ticket is always required.
robsablah@reddit
Questions are free... if you want us to act, that's a ticket
waxwayne@reddit
The question I always get downvoted to hell on is why don’t you create your ticket to track your work. Why is it other departments responsibility to track your work for you? If I call any customer service line even the worst ones like Comcast they don’t ask me to make a ticket they just enter whatever they need in their system. But sys admins are above entering tickets. I know you can do it because when the C-Suite needs something you just do it. The whole thing comes across as passive aggressive “I can’t work without a ticket” like you can’t put in your own ticket for the customer you are working with.
I remember I had a whole database system broken and I brought to managers notice. They asked me for a ticket to fix the system they broke. So I asked them if there was a ticket created when they made the change that broke the thing.
And yes when I was a sys admin I created my own tickets for customer task.
BarracudaDefiant4702@reddit
Depends on corporate culture. For me, generally if not resolved immediately (so don't forget) or takes over 15-30 minutes to do. Another condition is if it impacts multiple people even if it's only a quick reboot should probably have a ticket. That said, in general, it's better to create more than not enough. I am senior level so I mostly get larger tickets and if I put a ticket in for every little thing that comes in via slack or something it would take more time for the tickets then the work. Sometimes tracking that is important, but generally not. If 50% of your day is spent on sub 15 minute issues then you should probably be putting a ticket in for them so the volume can be measured, but I only deal with 1 or 2 day like that so I don't bother (most of my time is spent on much larger tickets or meetings, etc).
mxpx77@reddit
How else does anyone know wtf you do all day if you don’t have tickets for all of it.
gkar_of_Narn@reddit (OP)
They don't. That's part of the problem. Right as I got hired (about 18 months ago) , we got a new CEO who doesn't just accept what the IT department head tells him. He wants to see the numbers. IMO I don't think people realize what the benefits are of those tickets.
mxpx77@reddit
It’s a problem for us too. I’m constantly asking for tickets from people who argue with me about it. At times I end up submitting it myself or it just never gets logged.
not_so_wierd@reddit
I keep telling my users that tickets are the metric my managers use to see if I'm being productive.
Normally I'll use one of these - depending on the person I'm talking to:
- "I'm the only IT at our office, if there are no tickets they'll eventually decide there's no need for me and then you'll have to call whenever something happens."
- "How would you react if one of your employees spent all day working on stuff for your client, but didn't log it as billable time? You'd be angry with him, right? We'll my boss reacts the same when there are no tickets, he thinks I've pissed away the day.
Disastrous_Meal_4982@reddit
When I created the issue in the first place. It’s never happened, but hypothetically speaking… 😅
NetScr1be@reddit
I'm surprised after reading this thread that nobody (unless I missed it) mentions that tickets are the metric for deciding head count and budget for the support department (with any kind of realistic accuracy anyway).
It's how the value of the function is measured.
DariusWolfe@reddit
I'm... a little bit like this.
If it would take me more time to annotate and close out the ticket than it did to fix it, I'm not inclined to ask for one. I make an exception with things that specifically need to be documented; a branch office going down entirely is something you're going to want to document, as are policy or settings changes, etc.
Corgilicious@reddit
A ticket for everything. If the user contacts you directly, go to the system and enter a ticket for them. That way you can put the information as you know it in there, even if you open it and close it in the same session.
paishocajun@reddit
If I get a message followed by a "nvm figured it out" before I can respond, no ticket needed.
If it takes me longer to do the ticket than actually solve the issue, like "I can't find the software request page because they moved it again" which is a quick copy/paste for me, no ticket.
But probably 90+% of stuff needs a ticket
theEvilQuesadilla@reddit
In a perfect world, everything gets a ticket. In practice, I'm closer of mind to your coworker. For example, a dev locked one of his accounts yesterday and asked me over teams to unlock it. I keep a Zero Inbox, so I saw the message within a few minutes, unlocked the account, and gave him the ok. Neither of us made a ticket.
tarentules@reddit
I pretty much draw the line at password resets, everything else gets a ticket so that we have records for everything.
Sometimes I do make one for password resets if it's a user that calls about it often though.
03263@reddit
Bathroom breaks
bythepowerofboobs@reddit
No ticket?
Individual_Ad_5333@reddit
No ticket, no party. I have no problem with answer a quick question on slack Q. I'm seeing x is this for your team Type questions. Once you want me to act on it log a ticket
Particular-Way8801@reddit
I am "fighting" with my team for that :
Always create a ticket, even for something as trivial as a password reset or telling the user to turn on the computer or checking the cables (yes still a thing, magic box do not work without mana).
default time is 15 minutes for each ticket (can be debatable, but I insist on it)
like other people said, it is our trail for repeating issues, and repeating offenders also.
And sometimes, it is not urgent or we do not have time to do it, so, without a ticket, we would forget it.
caffz@reddit
If there’s no ticket, it didn’t happen.
sceez@reddit
Everything is a ticket.
Casty_McBoozer@reddit
The problem is y'all resolved it in 5 minutes from a chat message.
I would not act on it until they enter the ticket. That way they learn no ticket = no action
baz4k6z@reddit
Tickets are traces of what I do all day that my boss can see. No ticket = my boss does not see that I'm working. I don't care how small it is.
Sokanas@reddit
Depending on how the org works tickets are used for performance evals and auditing time, especially if the work is charged to clients or other departments.
That and you know, documentation of what / why / how / when / who of issues.
Can also be used to analyze common recurrent problems that can be work shopped,
enigmaunbound@reddit
Every service impact is a ticket. It's necessary to build organizational memory. It's required to build problem metrics. And it says up our SLA to the business. If it's just an end user question or minor issue like a mouse then I'm not so intent on a ticket. My personal metric is of its fifteen minutes or less of my attention, no ticket.
Independent-Sir3234@reddit
I only skip a ticket if the work was already logged and I'm just doing the agreed follow-up, like swapping a dead mouse or finishing a move request. Once service was interrupted or I changed system state, I wanted a ticket even if the fix was just a reboot, because the "5 minute" issues are exactly the ones people forget. We had a flaky SIP gateway like that and the pile of tiny tickets was what finally made the pattern obvious.
libben@reddit
Tickets tickets tickets tickets and more tickets.
JC0100101001000011@reddit
We ticket everything.
Smiles_OBrien@reddit
We had a conversation about this at the beginning of last year, and I think we've moved somewhat into the territory of "if it takes more time to make a ticket than it takes to solve the problem, just solve the problem." To be clear, this is more about 'drive by' requests, the "oh while you're here" kinda things
For the record, I disagree with this. It's not policy per se, but definitely a change in attitude. I'm fully a No Ticky, No Worky kinda guy, so I still try to keep to that.
unofficialtech@reddit
For #1 that’s straight up CYA
2 is job justification, also useful for trends and helping solve those one-a-year random issues
3 supports warranty claims and manages inventory (cost)
4 supports our development team with trends, or justifies removing the top in favor of a commercially supported product
MaTOntes@reddit
Ticket EVERYTHING. Every interruption kills your focus. LOG IT ALL!!!!
the_star_lord@reddit
Everything needs to be a ticket. Everything.
No ticket = it didn't happen (imo)
Incidents = something is or was broken.
Requests = "I want/need" type things / project bookings / development work
Problems = repeatable issues
Changes = I did or need to do something to fix/change/update something
KallamaHarris@reddit
Hi, this chat is not monitored. Sorry I can not accept tickets over Teams, please submit to blablable.ourwebsite
The it ain't my problem no more
BlockBannington@reddit
If it takes more than 30 seconds or approval is needed. Other shit they can request via a generic tech help slack channel. Was decided by higher-ups
hkusp45css@reddit
If it needs to be done, it needs to be documented.
It's that simple.
jcwrks@reddit
Many ticketing systems accept an email to open the ticket. It take the same amount of time to type out something in a chat as it does an email. It sounds like the person in question may not want to have tickets tied to his user. ;)
whatdoido8383@reddit
I create tickets for everything because that's how you justify head count. Managers/execs live off data, if you don't have the data your chances of proving your case are very low.
Adium@reddit
Anything related to the coffee selection or toilet paper supply. I’m not your administrative assistant, HR, or union rep. Minimum requirements are things that have electricity running through them, more specifically items with a silicon chip but realize that might be hard for some to determine
Oktober@reddit
When I immediately pivot to something else and completely forget about the last thing someone hit me up on teams for.
Serafnet@reddit
If you made a chance to the environment you need a ticket. Full stop.
Reboot a server? Ticket. Change a password? Ticket. Adjust a desktop setting for a user? Ticket.
This is assuming your tickets are Incident tickets.
I'm personally not a fan of using incident to document answering questions. If you want to capture those then service requests.
jimicus@reddit
I’m sorry, but your co-worker is flat out wrong.
Oh, sure, “it was no biggie, five minutes to reboot and we’re back”. But if you’re doing that every couple of weeks - when people inevitably complain that it’s happening all the time (which they will), the tickets raised are hard evidence you can take to management to get something done about the underlying issue.
hazochun@reddit
Ticket is for KPI so our remote manager knows we are doing stuff.
hellcat_uk@reddit
From the title I thought this was a when do you not create a support request for your 3rd party.
The answer being you if it was Microsoft or Cisco you only create one when a) you've already exhausted all possible solutions, including nonsense like doing the same thing multiple times or b) you need an external ticket to point upper management at to keep the heat off your team. Only then is it worth wasting time jumping through their hoops.
Internally, no ticket no cure.
VividVigor@reddit
Fix the problem if it is that quick. Then open the ticket yourself. Why is this not a default behavior? Too good to open a ticket on behalf of another person?
Bogus1989@reddit
no ticket?
doesn’t exist
rambleinspam@reddit
There is no line, everything gets a ticket. Even the question, hey should I put this in a ticket, should be a ticket.
Bright_Arm8782@reddit
You don't create a ticket when you don't want work done.
"No tickee, no workee!"
Lost-Droids@reddit
Everything, some are 1 click auto close as well.. BUT then its tracked and known and at some point we may look and see well we had more than 2x the normal of those so something is a little weird.. Lets check
bukkithedd@reddit
If you use a ticketing-system, then absofuckinglutely EVERYTHING gets a ticket. End of discussion, point blank and done. No ticket? No work done.
Very simple concept.
The reason is visibility. "Little things" might become a very BIG thing, and that very fast, depending on what said "little thing" is. Plus that there's always a priority to things. If the "little thing" turns out to be something that takes a lot longer than it should and thus something more pressing is pushed down the line, then that's a problem.
We don't use a ticketing-system, but that's also because we're a two-man department with fairly static systems. We *had* one, but it wasn't used, so I nuked it. We're also not tracked/measured in that way, so meh.
Bibblejw@reddit
So, this typically happens when the support ticket process becomes a little more onerous (usually when more metrics are added, so more fields are made mandatory), users tend to start trying to bypass the ticket process to get stuff done quicker.
What's happening is that they don't have visibility into *why* everything is a ticket, which is so that it can be tracked, measured and trended.
In most IT departments, if it's not in the ticketing system, it's bascially time that the staff weren't working. There are metrics for time tracking, for ticket closures and a bunch of other things.
Short answer: Everything needs a ticket. If IT are doing something, it needs to be associated with a ticket.
If your users don't want to submit a ticket, then one gets created by the service desk, tracked and closed.
gbsscc@reddit
You can have ticketsystems for helpdesk and for change Management and for PIM etc.
But thing is: you need proper documentation for everything
testprimate@reddit
Ticket to call ratio is one of my performance metrics so you bet your ass everything gets a ticket. Call me about an existing ticket? Yeah, I'm making another one just to record that you called about the first one.
j9wxmwsujrmtxk8vcyte@reddit
Tickets are documentation. If he wants to help without bothering the end usersy that's commendable but then it's his job to create the ticket.
Obvious-Water569@reddit
If there's no ticket, no work is being done.