1. Zelf HaloPSA implementeren zonder kennis, leidt vaak tot onbenut potentieel
Veel MSPs die HaloPSA zelf implementeren, benutten uiteindelijk niet het volledige potentieel van het platform. Je hebt in ieder geval wat kennis van het systeem zelf nodig en ook van (ITIL-)processen.
- De klant die de Halo-implementatie helemaal zelf doet.
- De klant die het sámen met ons doet.
- De klant die de implementatie helemaal aan ons overlaat.
Zodra klanten al eerder een redelijk gestroomlijnd servicedesksysteem gebruikten, zoals TOPdesk, dan werken ze meestal volgens ITIL-principes. En dan lukt het ze redelijk goed om HaloPSA zelf te implementeren.
Maar vaak vinden klanten de mogelijkheden van HaloPSA overweldigend. En dan vragen ze of wij het voor hen of samen met hen willen implementeren. Waar ze vooral tegenaan lopen, is dat ze de processen niet helder hebben. Ze willen het liefst aan de slag conform ITIL en hoe HaloPSA out of the box is ingericht. Maar vaak zien we dat 80% van de processen zijn ingericht volgens ITIL-richtlijnen en dat 20% eigen, unieke werkwijzen zijn. Dus is het nodig om de eigen processen nog eens onder de loep te nemen of om hier een proces op maat voor te maken in HaloPSA.
Daarom is de beste manier om het sámen te doen. De klant heeft namelijk kennis van hun huidige processen, wij hebben kennis van ITIL en HaloPSA, en zo brengen we dat op de beste manier samen in het platform.
2. Mensen hebben onrealistische verwachtingen van support vanuit Halo
Halo is de afgelopen jaren hard gegroeid. Vooral qua development en klanten, maar wat minder op het gebied van support. Onze klanten merken dat wanneer ze een vraag rechtstreeks bij Halo neerleggen, ze soms een week of twee weken op antwoord moeten wachten. En dat is natuurlijk niet fijn.
Daarom geven we altijd bij onze klanten aan: we hebben liever dat je ons tien keer voor niets belt, dan één keer niet. Dan zorgen we ervoor dat je zo goed mogelijk wordt geholpen. In de praktijk kunnen we namelijk 9 van de 10 vragen gewoon zelf oplossen. En soms hebben we daar iemand van Halo voor nodig. Voor extra uitleg. Of als iets gewoonweg niet werkt, wanneer er bijvoorbeeld een bug in het systeem zit.
Onze klanten kunnen dus altijd eerst bij ons terecht. De meeste bottlenecks lossen we dan zelf op. Hebben we de hulp van Halo nodig? Dan gaat het alsnog sneller om die vraag via ons te stellen, dan dat klanten Halo rechtstreeks benaderen.
3. We bevelen geen specifieke RMM-tool aan om te integreren met HaloPSA
We krijgen nog vaak de vraag wat de perfecte Remote Monitoring and Management (RMM-)tool is om te koppelen met HaloPSA. Maar hiervoor hebben we geen specifieke aanbeveling. In de praktijk zien we dat de meeste MSPs al gebruikmaken van een RMM-tool, zoals NinjaOne, N-Able en Kaseya. Voor de meeste RMM-tools is een koppeling mogelijk met HaloPSA. Daarom is het ook niet nodig dat we onze klanten een specifiek RMM-tool aanbevelen.
4. Het is een slecht idee om oude ticketgegevens te migreren naar HaloPSA
Veel van onze klanten gebruikten hun oude ticketsysteem als knowledge base. Dat snappen we heel goed. Want je hebt al een groot aantal tickets opgelost, je kunt de oplossingen weer gebruiken voor dezelfde soort vragen, én je kunt wat je voor die klant hebt gedaan weer snel terugvinden.
Zo wilde een klant van ons ook alle ticketgegevens overzetten vanuit Freshdesk naar HaloPSA. Maar dat betekent dus ook dat alle klanten meegaan, die geen klant meer zijn. En dat je contactpersonen migreert die niet meer bij dat bedrijf werken. Al die oude informatie komt in je nieuwe systeem terecht, anders is het niet meer te herleiden.
Maar is het verstandig? Wij vinden van niet. Zie je nieuwe ticketsysteem als een kans om het in te richten met een schone, goed georganiseerde database, vrij van overbodige of verouderde informatie. Wat sommige klanten doen, is één licentie aanhouden van het oude systeem om dat als naslagwerk te kunnen raadplegen.
Maar begin met een schone lei. Werk zoveel mogelijk tickets weg en neem die nog openstaan mee naar HaloPSA. En ja, er zijn nu wel integraties tussen Halo en bijvoorbeeld ServiceNow en Freshdesk beschikbaar, maar die werken nog niet helemaal zoals het hoort. Daarom nemen de meeste van onze klanten afscheid van het oude pakket zonder data te migreren.
5. Veel MSPs worstelen met het inkoopproces van hardware
Met name de kleinere MSP-bedrijven hebben moeite hiermee. Dat komt omdat alle medewerkers toestemming hebben om inkopen te doen. En dat wordt vaak chaos. Daarnaast zijn de workflows in HaloPSA altijd aan te passen, maar dat wil je eigenlijk niet voor het order-to-cash-proces.
En dat is logisch. Want dit proces verloopt zo goed als standaard. Je hebt een verkooporder, van die order wordt een inkooporder gemaakt, en dan gaat de bestelling de deur uit. Vervolgens wordt de hardware geleverd, gevolgd door een factuur. Dat is gewoon een rigide en vaststaand proces. Dit geldt voor HaloPSA, maar ook in Exact of Microsoft Dynamics is dit proces niet anders.
De medewerkers van de administratie hebben nu namelijk veel meer werk. Ze moeten steeds navragen: is deze hardware nu besteld? Klopt de prijs? En door je proces vast te leggen, voorkom je dat je zomaar een laptop of monitor ‘weggeeft’. Omdat je bent vergeten de hardware te factureren. Dat kan je zomaar duizenden euro’s kosten op jaarbasis. En dat voorkom je met een goed ingericht, standaardproces voor order-to-cash in HaloPSA.
Hulp nodig bij de implementatie van HaloPSA?
Doordat we nu enkele jaren HaloPSA als ITSM-platform bij onze klanten implementeren, weten we dat het slimmer is om HaloPSA sámen te implementeren, dat er geen specifieke RMM-tool is waarmee je als MSP moet werken, en dat het stellen van supportvragen aan ons je doorgaans een sneller antwoord oplevert. Ook weten we nu dat het geen goed idee is om je oude klantdata te migreren naar HaloPSA en dat het slim is een gestandaardiseerd inkoopproces in te richten. Doe er je voordeel mee!
Eerst zelf even rondkijken in de HaloPSA-omgeving, voordat je met een implementatie aan de slag gaat? Vraag dan de gratis trial aan. Je krijgt direct 30 dagen toegang.