Service Desk Kiosk

[Wood_ Jeremy]

Hello!

Our company is looking for a way to setup a Service Desk Kiosk. 

At its core, we are looking for a setup that allows for employees to walk up to and easily create a ticket for the service desk team to then follow up on. 

The primary challenge I am looking for recommendations on is that we need to know who put in the ticket so we know who to follow up with. Below are a couple of ways I can think of to do this but they each have drawbacks. 

If anyone in the community has ideas on how to either solve for the drawbacks of a solution or a completely different solution I would greatly appreciate the feedback!

---

Option 1: Make users login. 

Probably the most straightforward option. Is to make users login at the kiosk with their account and setup the kiosk to clear cache when the page is closed. (Likely using a private browser or some similar method.)

• This would be the same as a user sending a ticket from their own computer. 
• We are a manufacturing company with many "Labor" employees that need assistance with production equipment and we want them also be able to put in tickets. While all employees have accounts many only use their personal account once a year to sign up for insurance and then forget it even exists.
• One of our top ticket types is password resets. If you they don't know their password, they cant login, and then cant make a ticket to get their password reset. 

---

Option 2: Use a generic account with a kiosk request type

We could create a generic account to have automatically logged into the kiosks. None of our current request types ask "Who is this ticket for" because its just assumed that if you are putting in the ticket, you are the point of contact. For this solution we would need to create a new "Kiosk" request type with this functionality. 

• There is no easy way (that I know of) to restrict a user to one specific request type. So when logged in the kiosk account would have access to all of our other request types. If someone started clicking around they could very easily get to another request type and we would lose all the information for who is creating the ticket. 

---

Option 3: Create a new site (aka project) with only 1 request type

This is an expansion of option 2 but has its own drawbacks. 

• We want a single queue for our Service Desk teams to be working tickets from. If we create a separate site that's a completely different queue and location our techs now have to manage.

[Trudy Claspill]

Hello @Wood_ Jeremy 

Regarding option #3, you could add automation to immediately clone the Kiosk issue from the isolated project into your project that has all the request types that your Service Desk teams handle.

Given that you are going to ask for the submitter to self-identify at the kiosk (presumably by filling in a field with some information), then there would be no need to keep the kiosk request open. The submitter could be set into the Reporter field of the request you create during the cloning process, and the source Kiosk issue could be closed.