User: I need a new ssd to expand the storage on my laptop

C: Sure, for that laptop you need to submit an M.2 installation ticket.

User: No I need an ssd.

C: Yes sir, that is an ssd, it's just the form factor. Go to [company's internal website] and submit a request for an M.2 ssd installation.

User: They have 2 models to pick from, which do I choose?

C: The M.2.

User: ...Is that an ssd?

C: ...Let me just show you.

Dealing (primarily) with other techs

Rule T1 - CYA

Rule T1A - Always have someone else to blame it on.

Rule T2 - Never lie to another tech.

Rule T2A - Unless that tech is the person you're about to blame. See Rule T1A.

Rule T2B - Sometimes you will need to lie in order to deal with things like warranty repairs or getting ISPs to do the right thing.

Rule T3 - Never assume anything.

Rule T3A - Does the issue even exist?

Rule T3B - Is it even plugged in?

Rule T3C - Is it turned on?

Rule T4 - Don't expect your boss or coworkers or users to understand just what it is that you do.

Rule T4A - Even if they are a tech.

Rule T5 - Sometimes, you will be the one who is wrong.

Rule T6 - Don't try to do work over the Internet while in a moving airplane.

Rule T7 - Never call support with your cellphone if you can help it. Otherwise, you won't be able to drop the problem in someone else's lap.

Rule T8 - You will really screw up eventually and it is going to be a doozy.

Rule T9 - Backup following the Rule of Three. A backup, a copy of the backup, and a copy of the copy. Test them.

Rule T9A - Consider using other backup strategies. See Link TL1(https://www.unitrends.com/blog/3-2-1-backup-sucks).

Rule T9B - There is no backup. If there is a backup, it is either corrupt or years out of date.

Rule T9C - If you can't restore from it, you don't have a backup.

Rule T9D - If you haven't tested your backup recently, you don't have a backup.

Rule T9E - A year ago is not "recently".

Rule T10 - Assume that there are also inside threats, even inside IT. It's not paranoia if they really are after you (or your stuff).

Rule T10A - Don't trust your coworkers. They might be using Rule T2A.

Rule T10B - Don't even trust yourself. One error and you might cause serious damage or become a security leak.

Rule T10C - The new member on your team will send critical sensitive information to anyone who asks without trying to do any verification.

Rule T11 - When you need tech support, the tech support person is likely to be clueless.

Rule T11A - Whenever you have a problem, you will be unable to find a solution until just before the tech you called for help arrives.

Rule T11B - If the tech you called in isn't clueless, then you were and your problem has an obvious solution that you completely missed that they will point out seconds after they arrive.

Rule T11C - If none of these apply, the solution will be something random that will make no sense whatsoever to you or the technician.

Rule T12 - Every tech has their own set of Rules, even if they don't know it.

Rule T13 - Every tech is also a user.

Rule T13A - Techs will treat you like you are a user.

Rule T14 - Make sure your coworkers don't make changes before going on vacation.

Rule T15 - No technical person reads all of the rules. They will act like they know them until the place catches fire, then complain about incomplete documentation.

Rule T15A - Especially if it was the documentation that went up in flames first.

Rule T16 - Womprats aren't much larger than two meters.

Rule T17 - Third-Party IT will make configuration overhauls without notifying your company's IT department, and then blame your company for problems caused by their configuration mishap.

Rule T18 - You are incompetent. You just don't know it. At least, that's what your replacement will think.

Rule T18A - You will have to deal with techs who are incompetent.

Rule T18B - Sometimes, you really are incompetent.

Rule T19 - You might find people who support you. Reciprocate.

Rule T20 - Always verify who you are corresponding with. This includes not using Reply All.

Rule T21 - Use your inner laziness to do the most elegant solution possible.

Rule T21A - Know the difference between "truly lazy" and "plain laziness".

Rule T22 - If nothing seems to work, reboot.

Rule T23 - Cables can and will be used as ropes.

Rule T24 - Other techs will never read the manual.

Rule T24A - Neither will you.

Rule T25 - Your fellow techs will expect you to be their tech support.

Rule T26 - A tech will install equipment in dangerous environments.

Rule T27 - Third part IT will remove equipment and not tell you or the user.

Rule T28 - The biggest enemy of good IT is that they are outnumbered by lazy IT.

Rule T29 - Grow a beard so that people don't recognize you.

Rule T568A - white green, green, white orange, blue, white blue, orange, white brown, brown

Rule T568B - white orange, orange, white green, blue, white blue, green, white brown, brown

Rule T1000 - Buy stock in Boston Dynamics but sell all of it before 2029.

*****

GitHub: https://github.com/r/morriscox

Rules of Tech Support

Rule 1 - Users lie.

Rule 1A - It may not be malicious or willful, but Rule 1 is always in effect.

Rule 1B - Users assume you don't know they are lying.

Rule 1C - Users continue to lie as a result.

Rule 1D - When caught in a lie, users get angry.

Rule 1E - Users lie even when they aren't users.

Rule 1F - If they are not lying, then they are wrong.

Rule 1G: Accept that you will eventually have to lie to get the user to do what you need them to do.

Rule 2 - Explain everything as simply as possible.

Rule 2A - There is no language simple enough to make a user understand anything.

Rule 2B - Emojis are NEVER an answer.

Rule 3 - User caused problems are caused by tech support.

Rule 3A - As it's your fault, they don't want to be billed.

Rule 3B - All issues are user issues. If there are no users, no issues get reported, no tickets get created. Ergo, it must be users who are responsible.

Rule 4 - If it doesn't work, it is your fault.

Rule 4A - If it does, you had nothing to do with it.

Rule 5 - If you take the time to visit the user's desk, the problem will magically have fixed itself.

Rule 5A - Or the solution is bound to be really simple.

Rule 5B - Or the user left the office moments after entering the ticket, and won't be back for days. How long is uncertain as these users never use their calendar.

Rule 5C - Or when they do, they won't have shared it with you or they entered an all-day event as taking an hour.

Rule 5D - The problem will be solved by doing something you already asked them to but they said it didn't work. - /u/Responsible-Slide-95

Rule 6 - All users consider their situation to be more important than others, even if they know you are helping someone else.

Rule 6A - All users want VIP treatment.

Rule 6B - But they don't ever want to pay for VIP treatment.

Rule 7 - It doesn't matter how much time the user claims something will take. See Rule 1.

Rule 8 - Users never read error messages, if they read anything at all.

Rule 8A - If a user reads an alert or error message, they don't know what to do even if they can only do one thing.

Rule 8B - The more advanced degree a user has, the less likely they are to read anything.

Rule 8C - They will give the wrong error message.

Rule 8D - If a user receives an error, when asked what it says, the user will reply: "I don't know, just an error. I closed it."

Rule 8E - "Isn't it YOUR JOB to know that?"

Rule 8F - Users will not read you the entire error code or message or will read everything else.

Rule 8G - If the user reads you the error message in its entirety, it will be irrelevant to the issue.

Rule 9 - Expect any and all jargon and technical terms (such as wireless) to be misunderstood.

Rule 9A - Expect everything to be misinterpreted.

Rule 9B - All jargon is the same to users.

Rule 9C - All jargon will be used incorrectly.

Rule 10 - About half of tech support is solving issues that are only partially related to what is supposed to be fixed.

Rule 11 - No system is idiot-proof enough to best all users.

Rule 11A - If you haven't found a user able to best your system, it's because they haven't found you yet.

Rule 11B - Nature will take as a challenge any attempt to create an idiot-proof system.

Rule 12 - There is nothing so stupid that no one will do.

Rule 12A - Stupid questions do exist.

Rule 12B - There is no such thing as a stupid question, just stupid people. Asking a stupid question identifies a stupid user and therefore the question itself is not stupid.

Rule 13 - Never believe a user who claims that there is nothing that needs to be saved. See Rule W10 and Rule W10A.

Rule 14 - Sometimes you need to trick users in order to get the job done.

Rule 14A - Sometimes you have to make people, not just users, terrified to get them to do what they are supposed to.

Rule 15 - Users care more about things working than in how you pulled it off.

Rule 16 - A user's appreciation for your work is inversely proportional to how difficult it was.

Rule 17 - If you have an accent, then you will be perceived to be in a foreign country.

Rule 18 - Never trust a user.

Rule 18A - Everyone is a user. Even you.

Rule 19 - The most intelligent person you know will be defeated by a mere computer.

Rule 19A - Even if it's you.

Rule 20 - The quickest way to find out who is responsible for something is to do the scream test. Remove that something and see who complains.

Rule 20A - If nobody screamed instantly, users may wait until it has been long enough that the thing has been thrown away and can't be recovered any more. Then you will learn that said thing was critical for some task that absolutely has to be done right now, just like every X years.

Rule 21 - Never underestimate the power of the end user to complicate things.

Rule 22 - If it looks different, then it's broken.

Rule 23 - Never give a user options.

Rule 24 - When you receive a ticket and call the user immediately they definitely won't be at their desk.

Rule 24A - If you email them they will already be on vacation.

Rule 24B - The less time that they're in the office, the more urgent their issue is.

Rule 25 - Watch out for Finagle's Law which states that 'Anything that can go wrong, will — at the worst possible moment.'

Rule 26 - Always have a small list of phrases to get users to do what you are trying to get them to do.

Rule 26A - Only share these with other techs.

Rule 27 - Don't let people know you are a tech. They are likely to ask for free tech support.

Rule 27A - Never, EVER, give out personal contact information.

Rule 28 - Sometimes, you will be the one who is wrong.

Rule 29 - Expect equipment to be placed in bad locations.

Rule 30 - It's always the printer|DNS|server|browser|connection. It's never the printer|DNS|server|browser|connection.

Rule 30A - It's always the printer. Printers are evil.

Rule 30B - Printers are evil because of users.

Rule 30C - If a document fails to print, users will keep trying just to make sure it prints.

Rule 30D - The true importance of the documents they are trying to print will be inversely proportional to the fit they are throwing.

Rule 30E - Users will mash buttons and go through random menus and do random actions until errors go away or the printer is messed up. See also Rule W84.

Rule 30F - Did you check DNS? Check again.

Rule 31 - All user provided information must be verified.

Rule 32 - If you are a female tech, users will ask to speak to a man.

Rule 32A - You will be the only one who can actually help the user even though they will not believe a girl really knows anything.

Rule 32B - You actually know twice as much as the male techs but get only half the respect.

Rule 32C - Guys will pay more attention to your looks/voice than your mind.

Rule 32D - You'll get tons of calls from men (especially if you are attractive) who will even disconnect stuff to get you to go to them.

Rule 32DD - Women will cause IT problems to keep you away from men.

Rule 33 - Just because it worked yesterday does not mean that it will today.

Rule 33A - Just because it didn't work yesterday does not mean that it won't today.

Rule 33B - Things only work when you are paying attention to them.

Rule 34 - Never refer to this Rule by its name.

Rule 35 - Updates will be both solutions and banes, usually at the same time.

Rule 36 - Sometimes, you have to nuke everything.

Rule 37 - Focus on getting things working, then on getting them done right.

Rule 37A - By hook or by crook.

Rule 37B - When things are working right, leave them alone.

Rule 37C - If something starts working, even if you KNOW what you just did shouldn't have fixed it, raise your hands in the air unthreatening-like and slowly back out of the room.

Rule 37D - You only think it's working. The real cause will wait a while and then break everything in a spectacular fashion a few months down the line. Luckily, by then it's usually no longer your problem.

Rule 37E - It will still be your problem.

Rule 38 - There's always a relevant xkcd.

Rule 38A - If you can't find a relevant xkcd, it's because you haven't looked hard enough.

Rule 38B - If there is no relevant xkcd, there is always a relevant Dilbert strip.

Rule 38C - If there is no relevant xkcd or Dilbert strip, there's a relevant entry in The Seventy Maxims of Maximally Effective Mercenaries. Link L1

Rule 38D - If you can't find a relevant xkcd, Dilbert, or Maxim, your problem does not exist.

Rule 39 - You and your work will never be appreciated since if you did your job right, none of these problems would have happened.

Rule 40 - All IT urban legends are true.

Rule 41 - If it takes TFTS to turn you paranoid, you likely haven't been in tech support for very long.

Rule 41A - You aren't paranoid. They really are out to get you.

Rule 42 - You already know the answer.

Rule 43 - Every tech is also a user.

Rule 44 - Never make changes before going on vacation.

Rule 45 - The more you specialize, the less you will remember about basic desktop functions.

Rule 46 - No technical person reads all of the rules. They will act like they know them until the place catches fire, then complain about incomplete documentation.

Rule 46A - Especially if it was the documentation that went up in flames first.

Rule 47 - Don't help anyone who is not paying you in some way as they won't take your advice seriously.

Rule 48 - Vendors will tell you that you need to upgrade to the newest version in order to fix things. If you are on the latest version, they will tell you to wait till the next version.

Rule 48A - If the problem remains reproducible on the latest version, they may tell you to downgrade. Even if you just upgraded per Rule 48.

Rule 48B - It's not a bug, it's an undocumented feature.

Rule 49 - Never assume anyone else is smarter than you.

Rule 49A - Never assume you are smarter than anyone else.

Rule 49B - A user's intelligence will always be precisely what is needed for maximum damage.

Rule 50 - Scheduled updates won't.

Rule 50A - Anything scheduled will break things, especially if you are not available.

Rule 51 - Drivers will drive you bonkers, if you can even find them. Even if you can find them they may not be compatible.

Rule 51A - Drivers are the real threat, not hardware.

Rule 51B - Drivers using hardware [heavy machinery] are also a real threat. Backhoes/diggers have a magnetic attraction to fiber optics and the drivers have an innate ability to find optical fiber. Link L2.

Rule 52 - No is the answer for every request as long as it's plausible.

Rule 53 - Treat your job like a role playing game. Link L3.

Rule 54 - Don't run stuff that you are not supposed to unless Rule 37 and Rule 37A apply.

Rule 55 - The Seventy Maxims of Maximally Effective Mercenaries are always applicable. Link L1

Rule 55A - Sometimes the applicability of the Maxims is not immediately obvious.

Rule 56 - Get to know the Dunning-Kruger effect. Link L4.

Rule 57 - You might want to consider starting the day with coffee or tea and ending with whiskey or scotch or bourbon or beer...

Rule 58 - Vendors might not follow standards.

Rule 59 - You might find people who support you. Reciprocate.

Rule 60 - When a user activates the Swedish Fish rule, they get preferential treatment.

Rule 61 - Like the military says, never volunteer.

Rule 62 - Some bugs are Heisenbugs; they can only occur if they are not being observed. Users do not count as observers.

Rule 63 - Something will be needed right after you get rid of it.

Rule 63A - Once you replace it, you will no longer need it.

Rule 63B - You will buy something and then find out that what you currently have already has what you needed.

Rule 64 - User managed projects will always fail.

Rule 64A - And they will blame you.

Rule 65 - You will complain about something and then realize that you are the one that is guilty.

Rule 66 - You will find yourself putting out fire after fire without any chance to document anything.

Rule 66A - Then get blamed for not documenting everything.

Rule 67 - Try using metaphors and analogies in addition to or instead of technical terms.

Rule 68 - The higher rank an employee is, the more problems you will have with them.

Rule 69 - Refer to Rule 34.

Rule 70 - Anything that will show up as a link should be a link.

Rule 71 - Never take actions that assume a system is a certain way.

Rule 71A - Especially if not assuming makes little or no difference to the troubleshooting process.

Rule 71B - And never if the incorrect assumption will be recognizable to the user.

Rule 72 - Always give users the least amount of access/permissions that you can realistically get away with.

Rule 73 - It's always Dave or Steve or Kevin. Unless it's a Karen.

Rule 74 - Try to phrase things in a way that helps users save face.

Rule 75 - Maintenance, and sometimes coworkers or users, will unplug things and plug them back in wrong or not at all.

Rule 75A - If anything goes wrong they won't tell anyone. You will get to handle the "website down!" or "the internet stopped working!" tickets.

Rule 76 - Only have the minimal required equipment needed for users.

Rule 77 - Your company will be in a very old very shoddy building.

Rule 78 - If someone is acting odd, it might be a social engineering attack. Verify everything.

Rule 78A - VIPs within the company that actually do have the power to have you fired at whim will be the most angered by attempts to verify and will be the hardest to verify.

Rule 78B - Social engineering attackers know Rule 78A.

Rule 79 - Users think they can connect to anywhere from anywhere.

Rule 80 - If this port is taken, port 443 will be as well.

Rule 81 - Most of your job is figuring out what users are talking about.

Rule 81N6 - The GoogleBing awaits.

Rule 82 - Temporary solutions aren't.

Rule 83 - Every company has a Production environment and a Testing environment. If you're lucky, they are separate environments.

Rule 84 - Users already have a certificate of proficiency in computering.

Rule 85 - Always let someone know that you are there to fix a problem.

Rule 86 - You might encounter a user who is nice, doesn't need everything explained, takes you seriously, reads you complete error messages, and does what you tell them to do with no drama. neigh Seriously, they do exist.

Rule 87 - Users who always demand the latest hardware never work in a position that requires the latest hardware.

Rule 88 - Sometimes you need a user to fix your problem.

Rule 88A - Only a user will find the real problem.

Rule 89 - You will be expected to be your own tech support.

Rule 90 - You will have to support software older than you are.

Rule 91 - The OSI model has layer 8 (user) and layer 9 (management).

Rule 92 - It's always a bad sign if someone is happy to see you.

Rule 93 - "Only one thing" never is.

Rule 94 - Hypothetical questions aren't.

Rule 95 - Every mail from the helpdesk or system administration will be too much to handle if it is longer than two lines.

Rule 96 - Business will demand more experience for their job postings than exists.

Rule 97 - Always keep copies of drivers you download.

Rule 98 - Don't ask users if something is on the screen. Have them read the screen.

Rule 99 - A fix will only work until you fall asleep.

Rule 100 - A theme, especially a system theme, will make it difficult to read anything.

Rule 101 - Urgent isn't.

Rule 102 - Someday you will forget to use the mute button. Double mute.

Rule 404 - You will never find it. See https://www.explainxkcd.com/404

Rule 404A - If a page is not found, then the entire site|Internet is down.

Rule 404B - Online manuals will disappear without warning. Download a copy for yourself.

Rule 600613 - Used to go to websites instead of going directly.

Rule Ferengi - Users want their problem fixed quickly. Bribes will ensure they will be.

This doesn't exactly fit but it's close enough.

This was in 2016 or 2017.

A good friend of mine was in need of a new PC and wanted to buy a prebuilt. I gently (maybe not so gently) told him that was a waste of money and I could build a better one for cheaper. So I put together a decent budget oriented mid tier build for him. i5 and a GTX 1060 6gb. All was well at this point. We ordered the parts to his house and I got on a train to his city to put it together.

At this point in time, I wasn't an expert on building PC's. I had built two PCs in total. both very budget oriented.

So we (I) start building the PC. All goes well. Each part at it's place. Each cable connected (supposedly). Press the power button. doesn't POST. reseat everything. doesn't POST . My friend is getting very anxious at this point which is slightly annoying to me... Saying he should have just built a prebuilt. This in turn is making me uneasy. We decided to take it a PC shop so that they can test if a component is dead. And mostly to ease his anxiousness.

We take the whole computer, which is basically 'ready' in a cardboardbox to the pc shop. Taking public transit with a huge and decently heavy box isn't that comfortable. Arriving at the PC shop we explain the problem to the worker. He takes one look at it and goes: 'You haven't connected to 6pin power cable for the CPU'

Cue embarassment. But also relief that it was just a stupid oversight, fitting to my inexperience.

Back in his home, we connect the cable. It posts. all is good. Mainboard has no wifi built in so we get an ethernet cable. No connection. Ethernet doesn't work. I tried everything that I could and it didn't work. He bought a cheap usb wifi adapter. which works. To this day The ethernet doesn't work. He is still using that PC. I'm telling him he should upgrade it, or more like replace it completely.

He want's to buy a prebuilt. I tell him I can build him a pc for better and cheaper. I feel like im experiencing a deja vu. Hope the second round goes smoother..

I work in the IT department of a mid-sized company. One of my responsibilities is encoding newly-entered tickets (we use pretty old software for this, so auto-encoding isn't an option). Because of this, I get to personally greet every new ticket that comes knocking at the front door of our Service Desk, from the frustratingly complex to the yawn-inducingly mundane. This ticket fell in the latter category, and came across as follows.

>NEW TICKET: Desk phone is not working

>[Head of HR] has opened a ticket

>Comments: My desk phone does not work. There is no dial tone, but there is a message for me that I cannot retrieve.

The head of our HR department isn't exactly the most tech-savvy, but she's polite and (usually) puts in tickets instead of calling us directly. That, plus her elite status in the company, means we usually give her tickets a higher priority.

Phones aren't normally my area, but I figure that something like this shouldn't be too hard. The first few thoughts that cross my mind include some imaginations of the HR lead somehow managing to unplug her desk phone completely and some speculations that she may have swapped out the typical receiver with a faulty headset. To test these theories, I call her desk phone from mine. It rings all the way through, and then goes to voicemail. From this, I conclude that the phone must at least be connected.

Since I'm a fairly organized (read: obsessive) person, I quickly type a note of what I've tried in the ticket, and submit a comment that I'll stop over sometime that morning. After maybe two minutes, I get a reply back that I can stop over anytime. Not wanting to put it off until after lunch—as I've been known to do with "easy" tickets on occasion—I let my teammates know what I'm doing and scale the mountain leading to the executives' lairs. As I reach the top of the stairs, I immediately notice that the HR lead is in a meeting. She spots me, she gives me a look that says, "Sorry!", and I slink back to the dungeon where we IT people dwell.

As I go to update the ticket to mention that she was busy when I went to investigate the issue, the lady herself ventures into our cavernous halls. "Sorry about that, GrammarPanda. You should be able to look at the phone now!" I delete the update I was typing on the computer, smile, nod, and hike back to the office to take a look.

Walking into her office, I find her desk phone and immediately see that it's functional. The display is reading normally, and all the right lights are on. Okay, so it's definitely a receiver thing, I reason. I pick up the receiver, and find that the dial tone is, in fact, missing. But, in pulling the receiver to my ear, I notice two things:

1. I've never in my life seen anyone tangle their desk phone's receiver cord so badly; and,
2. The receiver is connected to some sort of sound amplification device.

This is when I recall that our HR lead is very, very hard of hearing. It was actually what made me suspect a receiver issue in the first place. But, I didn't realize that she installed this gizmo to help. Oh, well; it's pretty neat, and it makes sense. In any case, the device has several LEDs on its front, and none of them are on. I notice that the receiver is plugged into the device, and the device is plugged into the base of the phone. All the wires are securely connected, so either a cable is bad or the device isn't powered by the phone.

To check on this thought, I flip the device over. Right away, I see a battery compartment that (thankfully) has a pull tab and isn't screwed into place. I pop the panel off and see a puffy 9V battery. If someone would have told me that this battery was 30 years old, I would have believed them. I promptly remove the battery from the unit for proper disposal, retrieve a new one from the supply area, install the new battery into the device, and put everything back in place. Now, when I pick up the receiver, I hear a dial tone that could be used to call whales living in the ocean on the other side of the country.

Satisfied with this solution, I walk down the stairs and run into the HR lead on her way back up the stairs. When I explained the solution, she smiled gratefully, saying, "See, now I never would have thought to look for a battery!" "That's what I'm here for," I reply while returning her smile.

With that, I sneak back to my stalagmite-encased desk, type up the resolution, and close the ticket. Sometimes, solving a simple problem can be extremely satisfying—especially when users show gratitude like that.