Kaseya Community

How do you get staff to use Kaseya...

  • One of the biggest problem I face in my organisation is getting other people to utilize our Kaseya VSA.

    Most of them will use it as glorified remote control manager however getting them to really use it is like pulling teeth.

    The most common comments I have been given are;

    • Its to hard to learn
    • that its very different and the interface is not very intuitive
    • I don't have the time

    I can understand their comments about the interface but it has never held me back from using it. I have tried to document how to use some of the functionality, created them Kaseya Training accounts and given them links to to get access to the training material. I have even offered to sit with them and show them how to use Kaseya in their daily jobs however with no or little success.

    Then you will get the old enterprise trained "IT pro's" that work against you, unnecessarily duplicating work that you have done like deploying applications with GPO's when you have a Kaseya script to do it. Or they will mess with your deployment folder structure after you told them several times not to change it as it will break the deployment scripts and you end up with 3-4 deployment folder with duplicate files in them wasting disk space and the person who you know is going to be you that will have to clean it up.

    Its come to a point where I have given up as I have realised that it is a waste of time. I believe for it to really work it needs to come from the top and if you are not the boss or business owner and they don't want to listen to you then there is very little that can be done about it.

    So to get back to the discussion, how do you get people to use Kaseya when its easier for them to just use what they already know or get you to do it all for them?

    I know that their is no single solution for this but I would be interested to learn if any of you guys have had similar experiences and if you have figured out any tricks to make it work in your organisation.

  • I could have written this post almost verbatim.  

    The biggest complaint we get is that they don't have time to use other features.  I visited all our offices when we moved to 6.2 and offered the chance for users to sit in for a brief overview.  Some thought the knew it all and didn't bother, others only used the time to get away from their desks for a short period but the guys (and girls) that paid attention have a much better knowledge of what we can do.

    Regarding the change in folder structures and duplicate files, I'm hearing your pain, so we locked it down and there are only a couple of us that can now make those changes.  Has this worked?  For some yes, they ask if this or that can be created or used for downloading whilst I suspect others don't as they're in a huff.

    We ran a competition for suggestions for things we could add to the system, a lot of which we already had, but we got some useful info which was adapted.

    Don't think we'll ever get 100% buy in but we found that forcing users hands in certain ways, blocking other RC tools that were being used instead of Kaseya was our biggest problem however much I sympathize with them when Kaseya's RC is still as bad as it is.

  • I'd be surprised if you ever get 100% buy in. But I think that two things will help. One is, as Alistair Curran puts it, forcing people's hand. You lock down your folder structure, etc. You block certain tools, etc.

    The other thing is a change in approach. I'm sure you don't mean it this way, but you come off as rather dismissive of other people's concerns. It's nice that Kaseya's interface never kept you from using it. But that doesn't work for everyone. I understand that there is not much you can do about it, but approaching the issue with a bit more sympathy rather than a "get over it" and "don't be such a baby attitude" (which may not be what you mean, but what comes across in your comment) would probably be helpful. And don't be so hugely dismissive of your staff's experience. No one wants to do more work that necessary. So, find out why they are reinventing the wheel. What do they need to get them to use the Kaseya script rather than their old way? Why are they changing your deployment folder structure? What do they need to keep from doing that?

    And, by the what's the big deal with having several different deployment folders, if they really do slightly different things? I know you said that it wastes space, but really, if you are that cramped for space, maybe you need to look at upgrading your hard drives. Talk about "old time" thinking. Of course, the differences should be documented, but that shouldn't be that big of a deal.

  • I think you're right, HardKnoX. If management isn't behind it there isn't much you can do. You might want to speak with the appropriate management and remind them how much money and effort has been spent on providing this tool and perhaps you can show them where not using it globally is costing them time and money. One would think they'd respond to financial reasoning.

  • At this point I would be happy with 50% buy in if I could get it, the way I see it is I'm mostly self-thought in Kaseya the parts of the VSA that I want people to use is not rocket science.

    @Kasyza I don't think I'm being dismissive of their concerns, I just can't change the way the VSA portal looks and works its something we all have to work with.

    @Alistair good to know that I'm not the only one with this problem, enforcing structure would be nice however these guys know what they doing and have the ability to override anything I lock down and they have numbers on their side.

    @zippo financial reasoning is a good angle, I will need to start using that more over my techie logic side Big Smile

  • We're all the same.

    However i believe that engineers are afraid of kaseya because it ultimately means the end of their jobs or at least in an ideal world it will mean the end of their jobs.

    Lets be serious the whole point of kaseya is to reduce the engineer to customer head count.  

    We just made a bunch of people redundant and the official word that went out to the media was because of the progress we have made in automation. I can tell you the automation was in spite of the engineers as apposed to with their help.

  • In my case it would not cause anybody to become redundant to use the VSA but would allow them to become more efficient in their jobs by getting the information they need faster and not having to duplicate work.

    The flip side to this is that if people can find ways not to use Kaseya to do their jobs it will become redundant in those organisations.

  • This is a great thread and something I have been discussing with many MSP's over the years of all sizes. At the heart of this is IT Automation. Like it or not part of the fundamental reason we all use IT is to Automate and make some process more efficient, not just in IT but in every facet of business and even our daily lives. Most of the purpose of Kaseya is to allow IT Pro's to do the same thing to IT that IT is being used for in all other areas of business - Automate.

    So this creates both an opportunity and a challenge for businesses and IT Pro's alike. I believe it all begins with the fact that you need to really truly understand a process before you can automate it. To avoid some of the complexities you can of course automate just a part of some process, and leave other parts manual. And so most of the automation of IT is finding that balance.

    Like it or not it takes a certain kind of person to spot, understand and even care about that balance. Not every IT Pro is ready or cut out for it. When some of us see a hammer, we see a device for putting in a nail, for a gifted carpenter they see the house they are going to build with it. How well do you need to know a subject before you see possibilities instead of just tools?

    I only point this out, because I think the answer to this comes down to a number of factors and where the concept and ability to take advantage of Automation is up to:

    a) Level of IT the IT Pro's and their ability to 'spot' automation opportunities

    b) The 'openness' of a business to learn and adapt and take advantage of these opportunities

    And as with all things it is often not quite so black and white as this, different people and different parts of a business will all take the concepts on at different rates.

    And so I always encourage those in their quest for IT Automation to simplify and put things into a few simple baskets, Tools, Delivery Based and Service Based.

    Tools - these are simple 'plug and play' elements that allow you to carry out a manual task more efficiently and require little to no understand of automation - Remote Control is a good example

    Delivery Based - Items that only require a few decisions and basic manipulation in order to put them into broad use, in Kaseya I think of items like  - KAV - Anti-virus, KSDU - Software Deployment and update

    Service Based - Items for which I am going to need to understand what it is I am trying to automate in order to apply the right kind of process - things like a Service Desk, Scripting (Procedures), the more complex elements of monitoring, and even Backup and Disaster Recovery to some extent, as I need to be keenly aware of my business objectives to fit the solutions to the requirement.

    So I do agree with Hardknox's sentiment, that if you adopt even the most basic of Tools you can become more efficient, and that any person or organisation that can not absorb the concepts at some level will eventually fall behind.

    Do your very best to light the path to eventual Service Based approach and the epiphany of complete Automated IT, but remember there will people and parts of an organisation along the way that may just need/want to stick to Tools, because either that's where they or their process is up to, or because they are not ready for anything else just yet.

    But keep up the good fight!

  • The whole idea of our staff not using Kaseya is foreign to me.  I never even have thought about it. Even when we first adopted it 5+ years ago all our staff jumped right in.  

    Educate users as to how powerful it is. this is the most useful tool.  Do not overwhelm them, but show just one or two things at a time and build from there.

    Reward people for finding new uses for it

    Cut off recourses they may use to bypass it

    Use peer pressure to embarrass them when they do it the old hard way, (AKA a 5 minute script to perform work on 500 machines)

    Most importantly, don't let them get away with it. If you can not do that, then you have to get those on board who do have that power.

  • @ James V - All I can say is that you have been very lucky with the adoption of Kaseya in your organization, so far I have worked for to companies doing what I do with the same result. Yesterday I found out that the guy I have been training for the last 12months is leaving so I'm pretty much back at square one.

    (Any techs living in Auckland NZ looking for a job that has some Kaseya exp message me)

  • Don't look at it like you're going to get rid of techs by using Kaseya.  Look at it like you can take on more clients by being more efficient.  As we are streamlining our internal processes, we are ramping up our marketing efforts to take on more clients.  Gives our sales people something to do too. :)

  • Eric Christiansen

    Don't look at it like you're going to get rid of techs by using Kaseya.  Look at it like you can take on more clients by being more efficient.  As we are streamlining our internal processes, we are ramping up our marketing efforts to take on more clients.  Gives our sales people something to do too. :)

    Most techs aren't silly enough to believe that marketing stuff.

    And with a large number of clients moving to a cloud model like office 365 they are already worried about the reduced workload for themselves as servers disappear.

    For New Zealand which is a small country (4million) the SERVER IT support industry is going to go through a huge down turn over the next 5 years as most small companies make the move to the cloud.   

     



    [edited by: Michael Dixon at 3:16 PM (GMT -7) on May 6, 2013] kj
  • Our techs never looked at Kaseya as a threat, only as a cool useful tool. Sure it does save us from more "labor" but honestly, it does the work that no IT guy wants to do anyway!  Patching! Watching Event logs! System Cleanup! Software Deployment! What worthwhile tech wants to do theses kinds of things?   We call our Kaseya the Quite work-a-holic.  It is the most loved employee next to the coffee maker.

    As to there concern about loosing work, come over to the States, IT unemployment as at an all time low. It is a pain in the butt to find good techs.

  • How people view it may also depend on how they get paid too. while kaseya does boring stuff it's still doing work that a tech could do and now they're not doing it they have to find more work.

    Things like patching was easy money/time for them.

    Also the whole point of kaseya is to go SOOOOOOO much further than the simplistic things you mentioned.  Your meant to be using Kaseya to detect problems then Kaseya can resolve them with out anyone involved.

    How can doing the above NOT be seen as a threat to their jobs when in a idealistic Kaseya world Kaseya would detect and repair all problems and therefore there is no need for any techs.  

  • I would agree with Eric for us Automation is not really a job threat.

    If Kaseya could do all possible automation out of the box it would be a threat but it can't and still requires somebody to put that functionality in.

    On top of that  Kaseya does not always work as expected and you still need the human aspect to manage, maintain it and in worse case scenario manually do some of the jobs when it breaks down.

    Most of our customers still want human interaction and if you don't talk to them enough they become easy targets for other IT companies. So unless you are in a bloated organisation automation can only help making your service delivery more consistent.