/build/static/layout/Breadcrumb_cap_w.png
08/29/2018 300 views
Bit of advice would be appreciated, from anyone who's experienced a similar situation, or even just has ideas.

We've got a few departments expressing interest in utilising the K1000 purely as a Helpdesk, some of whom are involved already, some who are just end users at the moment. If it goes through, they'll be using Queues/Processes in Kace for things like external customer interaction (eep!), internal work/process tracking etc.

Thoughts around this currently are based on a 'Queue for each department' type setup, with customised Queues with custom rules for each particular Department's needs. The concept of managing all this is starting to make my head spin a little, so I thought I'd see if any of you clever bunch have had similar experiences.

Whilst it's obstensibly built as IT systems management and Helpdesk, anyone else utilising the Queues in K1000 for 'external' departments to IT? Any advice? Anything you wished you'd never done? Anything you wish you'd done from the start?


2 Comments   [ + ] Show comments

Comments

  • This is just a quick comment but interestingly enough we have just started that and running into some small issues at the moment. So far we just created another org for the second one but running into issues with Roles and minor functionality. Other than that it seems to be working ok so far. The issue we have (literally a post just before yours) is users switching from the new org back to the IT org. Hopefully someone out here can help us both out on this one. Best of luck to you HT ... hope we both can benefit from the others learning out here. :)

    Charles.
    • Just out of curiosity, why do you have different orgs for different queues, and not multiple queues in one org?
  • I'd be interested too as to why you chose that - we considered creating another org for our customer-facing helpdesks, as there's no 'contamination' possible then, but for the moment we're working within the same org - There's no plan for anyone external to the company to log into a portal, so it should all be done via email and so we shouldn't have to worry.


Community Chosen Answer

2
We actually have four active non-IT queues right now, with two or three more in consideration.  Two of them are for remote support of clients we consult for, and the other two are for process management in our manufacturing locations. They're all working well, and I manage them from a KACE administrator standpoint (adding and removing ticket owners, categories, etc.), but they manage their own day-to-day usage.  

When another department expresses interest in having a queue, we have a meeting and I give them a sort of sales pitch praising KACE's abilities, etc.  I'll answer any questions they have, and explain that while KACE is pretty flexible, they may need to adjust their procedures to make things work.  We'll choose an administrator/champion who will lead the project from that department's end, and schedule another meeting to go into detail.  At that point, they will explain their procedure and we'll translate it into a ticket life cycle.  I give them a sheet to fill out, which is basically all the fields from the queue configuration pages, and once they do that, I can create their queue.  

The most important thing for me is that they have everything in place procedure-wise before we start, and to set the expectation that once the queue is built and in place/in use, we're not going back and making major changes.  Little things are ok, (like I said before, adding and removing ticket owners, etc., things I'm not giving them rights to do), or if we run into a technical limitation and have to reconfigure something, but no redoing the whole queue.  That, and once the queue is in place, they're responsible for managing their own tickets.  I'm not watching their queue, assigning their tickets, etc.

The one annoyance I have right now is that there is only one KB.  While I can limit the articles that can be seen by anyone when they go directly to the KB, any ticket owner in any queue can append any KB article to their tickets.  So since the limitations are not in effect there, I can't put things that are for IT eyes only, so it becomes less useful to us.

We've been very successful overall with our queues, and with procedures and expectations in place, you can be, too.
Answered 08/29/2018 by: ondrar
Second Degree Brown Belt

  • Thanks! I'm putting together a Spec Sheet already for the Queue, but it's good to have some encouragement from someone who's already done it!

    For us it's the appeal of 'owning' the data internally on a SQL database which we can do whatever we'd like with, over an external system like Freshdesk et al which we don't have that kind of control over.

All Answers

0
Hello, we have tried to set up two non-IT queues, one for an admin department who handle public enquiries (not IT ones) and one for Estates for staff to report the usual day to day stuff that happens (wobbly desk, loo blocked etc).  In both cases the people who were going to use the queues found them too difficult to use.  We tried several iterations of the layout, cutting down fields etc., but the general response was that it was too clunky for what they wanted.  So that project fell by the wayside.
Answered 09/05/2018 by: Tea_monkey
Senior White Belt

  • Hey Tea_monkey, thanks!

    One of the departments who want to use the helpdesk is similar to your Estates department, as it's combined Facilities/Health and Safety, so wobbly desks/blocked loos are their stock in trade!

    It's interesting they didn't like it. I suppose there's always a fine line to tread. We're going to try using the Kace GO app for our facilities guys, as the idea of being able to upload their own asset barcodes and scan them to raise tickets or edit info is appealing to them for tracking maintenance/testing etc.