Dear Users… (A thread for Sysadmin, Technical Support, and Help Desk people) Part 10

[xterra]

I always use DDMMMYYYY, i.e. 07AUG2022.

Look up ISO 8601, which establishes

an internationally agreed way to represent dates: YYYY-MM-DD
For example, September 27, 2012 is represented as 2012-09-27.

Arth could use this as justification for a change in the date format in his situation.


https://www.iso.org/iso-8601-date-and-time-format.html

 

[RecoveringYuppy]

Look up ISO 8601, which establishes

Arth could use this as justification for a change in the date format in his situation.

That solves one problem and exacerbates the main problem that humans are typing these dates. catsmate's solution is less likely to be typed incorrectly and more likely to be correctable by someone else if it is typed wrong in the first place.

 

[Wudang]

That solves one problem and exacerbates the main problem that humans are typing these dates. catsmate's solution is less likely to be typed incorrectly and more likely to be correctable by someone else if it is typed wrong in the first place.

And is less likely to be read wrong. A project I worked on we had to get extracts from a hospital's database which was based around the US company Cerner's system and a homegrown datawarehouse. The former used variants of US formats with day and month in the opposite order from the DW which used largely UK data formats. Often we had to guess which format a column used. The few that were free format were a nightmare. And being hospital records you don't want to risk errors.

 

[alfaniner]

And is less likely to be read wrong. A project I worked on we had to get extracts from a hospital's database which was based around the US company Cerner's system and a homegrown datawarehouse. The former used variants of US formats with day and month in the opposite order from the DW which used largely UK data formats. Often we had to guess which format a column used. The few that were free format were a nightmare. And being hospital records you don't want to risk errors.

At least before the turn of the millennium, one could figure out which position the year was in, in a six-digit format. Once we got to 2001 and beyond, trying to figure out something like 050308 without a format definition was nigh impossible. I found that problem mostly with expiration dates on stuff in my cupboard and refrigerator.

 

[Blue Mountain]

At least before the turn of the millennium, one could figure out which position the year was in, in a six-digit format. Once we got to 2001 and beyond, trying to figure out something like 050308 without a format definition was nigh impossible. I found that problem mostly with expiration dates on stuff in my cupboard and refrigerator.

Relevant XKCD: https://xkcd.com/1179/

(Note that there's another joke in the mouseover text.)

 

[arthwollipot]

Seems to me like there should be separate fields for the date and number of contacts, right there and visible, so you don't have to play with text strings as the title.

You should put in a service request for that change!

In an ideal world, yes. But for now, putting it in the Short Description (ie. title) field works well enough.

Another peeve I have with On Hold incidents. We currently have a number of staff working Incident Management who will take a job, send an email to the client saying, basically, "Here's how to fix the problem: do this, do this, do this and reboot. Let us know how it goes." And then they put the incident On Hold. The instructions they are sending are reliable and are known to fix the reported issue.

To me, this incident should be Resolved, not placed On Hold waiting for them to contact us to tell us it worked. People don't do that. Once they've got the problem fixed, they don't care about our incidents any more. Doing a followup wastes my time and theirs.

Ah well. I have a week off next week. It's been prearranged for ages because I knew that by about this time of the year I'd need to take some downtime. And I do. Thanks, past me!

 

[Norman Alexander]

In an ideal world, yes. But for now, putting it in the Short Description (ie. title) field works well enough.

Another peeve I have with On Hold incidents. We currently have a number of staff working Incident Management who will take a job, send an email to the client saying, basically, "Here's how to fix the problem: do this, do this, do this and reboot. Let us know how it goes." And then they put the incident On Hold. The instructions they are sending are reliable and are known to fix the reported issue.

To me, this incident should be Resolved, not placed On Hold waiting for them to contact us to tell us it worked. People don't do that. Once they've got the problem fixed, they don't care about our incidents any more. Doing a followup wastes my time and theirs.
Ah well. I have a week off next week. It's been prearranged for ages because I knew that by about this time of the year I'd need to take some downtime. And I do. Thanks, past me!

Auto reminder at 7 days: no response = call closed

 

[arthwollipot]

Auto reminder at 7 days: no response = call closed

As I have related before, it's first contact - 3 days - second contact - 3 days - call closed. As the person who does the late shift most often it usually falls to me to do the second contact. It's a pretty easy job, especially since I have boilerplates to copy & paste:

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally), or reply to this email, and advise whether you still require help with this issue. We may be able to provide additional assistance over the phone.

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally), or reply to this email, and advise whether you still require assistance with this issue. We contacted you on 01/08/2022 requesting additional information, but have not yet received a reply.

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally). We will need to remotely access your computer in order to resolve this issue.

--o--

This incident is being resolved as we have attempted to contact you several times with no response received. Should you have any further questions on the matter, or if the problem reoccurs, please either reopen the incident in the Service Desk Portal using the link above, respond to this email, or phone us on extXXXXX (XX XXXX XXXX if calling externally).

--o--

20220810 *1 contact made*
20220810 *2 contacts made*

 

[Norman Alexander]

As I have related before, it's first contact - 3 days - second contact - 3 days - call closed. As the person who does the late shift most often it usually falls to me to do the second contact. It's a pretty easy job, especially since I have boilerplates to copy & paste:

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally), or reply to this email, and advise whether you still require help with this issue. We may be able to provide additional assistance over the phone.

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally), or reply to this email, and advise whether you still require assistance with this issue. We contacted you on 01/08/2022 requesting additional information, but have not yet received a reply.

Please phone the Service Desk on extXXXXX (XX XXXX XXXX if calling externally). We will need to remotely access your computer in order to resolve this issue.

--o--

This incident is being resolved as we have attempted to contact you several times with no response received. Should you have any further questions on the matter, or if the problem reoccurs, please either reopen the incident in the Service Desk Portal using the link above, respond to this email, or phone us on extXXXXX (XX XXXX XXXX if calling externally).

--o--

20220810 *1 contact made*
20220810 *2 contacts made*

There you go.

 

[gnome]

We did that for a while at my workplace. Then we moved to a system where the ticket was marked "Resolved" if the tech believed the problem was solved. The user could reopen the ticket at any time in the next three days and say there was more wrong. After three days with no contact it was marked "closed". If the user called again after that you started a new ticket and put in a link to the previous ticket.

 

[arthwollipot]

We did that for a while at my workplace. Then we moved to a system where the ticket was marked "Resolved" if the tech believed the problem was solved. The user could reopen the ticket at any time in the next three days and say there was more wrong. After three days with no contact it was marked "closed". If the user called again after that you started a new ticket and put in a link to the previous ticket.

That's exactly what we do. Except that apparently some of us don't.

 

[TragicMonkey]

When I worked as support for a bunch of hospitals the children's hospital was always quick to add "for the children!!" in every ticket and call, to emphasize how much more urgent and important their problems were. A printer is spitting out an extra sheet of blank paper after every once-daily batch print? For the children!! highest priority. Much more so than every anesthesia device in ten operating rooms stopped working.

The CHILDREN!! business soon stopped after a new manager was put over support. He reasoned that if each ticket were truly that incredibly urgent we should of course contact the user immediately and constantly to keep continual updates on these urgent fixes. Including calling them at home in the middle of the night and if we couldn't reach them moving up their chain of command until we got someone.

Apparently presidents of hospitals do not enjoy being woken at 3 a.m. over a printer issue on one workstation at a secretary's desk. Ticket priority was more carefully assigned after that, and the children's hospital sulked for two whole years.

 

[gnome]

I like it when priority designations are descriptive, for example, choices indicating how many people are affected, whether it stops work, incurs significant risk, etc.

 

[TragicMonkey]

I like it when priority designations are descriptive, for example, choices indicating how many people are affected, whether it stops work, incurs significant risk, etc.

Agreed. Later we got a more modern system going, where users entering tickets indicated impact in both severity and extent, and the priority would then be assigned by the software assessing both values. Rather than letting the user decide on a scale 1 to 5 how critical it is. A serious problem for one person might equal a minor problem for a thousand people, depending. Much better than letting an irritated nurse vent her frustration about "a too-clicky mouse" in the middle of the night.

 

[Gord_in_Toronto]

When I worked as support for a bunch of hospitals the children's hospital was always quick to add "for the children!!" in every ticket and call, to emphasize how much more urgent and important their problems were. A printer is spitting out an extra sheet of blank paper after every once-daily batch print? For the children!! highest priority. Much more so than every anesthesia device in ten operating rooms stopped working.

The CHILDREN!! business soon stopped after a new manager was put over support. He reasoned that if each ticket were truly that incredibly urgent we should of course contact the user immediately and constantly to keep continual updates on these urgent fixes. Including calling them at home in the middle of the night and if we couldn't reach them moving up their chain of command until we got someone.

Apparently presidents of hospitals do not enjoy being woken at 3 a.m. over a printer issue on one workstation at a secretary's desk. Ticket priority was more carefully assigned after that, and the children's hospital sulked for two whole years.

Brilliant! Sometimes the cleverest response is to play the game.

 

[arthwollipot]

Okay, this is the weirdest ticket title I've ever seen:


(click for clearer image)

 

[BowlOfRed]

Doesn't seem that weird. A bit incoherent. Do you have any tickets in your system that are completely and totally incorrect for the system they were submitted to?

I think we have one in ours where someone logged a ticket because he needed to board a train in about 30 minutes.

"Please help. I'm at <station> and need to get on the <x:xx> train to <destination>"

Yes, this is our standard IT help ticket system that thousands of people prior to him were able to understand was usable for email problems and password changes and other IT services. Maybe he confused "IT Ticket" and "Train ticket"?

(There were no further comments from the user on the ticket. It was simply closed. I don't think there was any sort of explanation trying to disabuse him of our ability to purchase travel vouchers at short notice. I hope he caught his train...)

 

[arthwollipot]

Doesn't seem that weird. A bit incoherent. Do you have any tickets in your system that are completely and totally incorrect for the system they were submitted to?

Of course. I call it a sparrow in the stairwell. One time we had someone call the Help Desk (it was before they were called Service Desks) because a literal bird had become trapped in a stairwell.

As it turns out, I think I know what this is supposed to be, and no, it shouldn't have come to us. It's a HR/Recruitment thing.

 

[Norman Alexander]

Okay, this is the weirdest ticket title I've ever seen:

[qimg]http://www.internationalskeptics.com/forums/imagehosting/thum_433262f1db9c38178.png[/qimg]
(click for clearer image)

Is there a system called "Transcend" in your organisation? Something that sounds like that? Or an HR process with that name?

Because a Director-of-(Nursing | Numptiness | Nothing) called Rodney is being killed by that method.

It's HR, regardless.

 

[arthwollipot]

I've actually done some sleuthing and worked it out. A DoN is a Deed of Novation, which is used to legally transfer the rights and responsibilities of a contract from one entity to another. In this case the DoN was executed to transfer them from a person named Rodney to an organisation named Transcend.

i.e not HR but Legal.

It was cced to a bunch of other people. I closed the ticket with the comment "No action required by Service Desk".