KACE Product Support

That is more of a process question then a setup. What are the differences between service, problem and change tickets? There there is no difference and you can report based on category you may not need it. If you can't do that then setting up the drop down would but it would be just one more thing your users would have to select from.

for our organization, we Service Desk create the tickets, not our end users. The end users actually call/email us with issues.

Service would be like those frequently submitted issues where we can resolve while on phone with end user and close ticket without having to assing to anyone.

Problem is where we basically have to create and assign to second level team to fix

Change is for change mangement which is basically ticket for doing changes to production environment. This one we would enable the approval field/function.

I see no problem creating custom field with those options to pick from, but Just trying to see if anyone out there does it same way and or similar!!!

Sounds good...for what you are trying to do I would just create the drop down and let your techs fill it in when the user calls. Training will be minimum as you just have to make sure your techs understand the drop downs.

if you are looking to move to the second level you might want to create a separate queue and call it level 2 and move tickets over to it as needed and have a different group of people working on those tickets.

The beauty of the KBOX is that you have many options to choose from.

I see no problem creating custom field with those options to pick from, but Just trying to see if anyone out there does it same way and or similar!!!


I am a junior tech that has been tasked with producing a change management queue. This is the config, sorry for the format, the pics wouldn't post and I'm not sure if they got embedded.


Status

Opened - Initiate Stalled
Assessment in progress- Initiate Opened
Scheduled- Initiate Opened
In build - Design Opened
Waiting for build approval - Design Opened
In review - Design Opened
Waiting for review approval - Design Opened
In Implementation - Deploy Opened
Approved - Deploy Opened

Notice the different states. Any user can open a ticket however, making each following status open will force approval when moving to the next status. (ex. Open>Assessment in progress=no approval , but going from Assessment in progress>Scheduled=requires approval)

Opened – Ticket is opened and selected approver is notified.
Assessment in progress - Initial ticket is viewed for relevancy. Explain the drivers of the change. List and describe the alternatives to the decision that was finally made and why they were rejected.
Scheduled - Communicate the high level project goals, objectives and plans; describe the change that will be taking place. List the audiences for the change and the benefits/risks associated for those groups.
In build - Provide a live action pilot/prototype.
Waiting for build approval – Does this pilot/prototype integrate into the current system? Does it satisfy goals?
In review - Evaluate pilot/prototype for efficiency. Waiting for review approval- Back out/revert to original system? Proceed with Implementation In Implementation - Authorized changes implemented into current system
Approved – Implemented changes are reviewed

During each of these milestones, users and approvers are able to leave comments about their submissions. Only one file attachment per ticket may be associated. After the ticket is opened, each following status change requires authorization by an appointed approver.

I didn't customize anything else really, but I have made the above guide to accompany the queue. PM me, I'd like to hear from you. Please make suggestions.