Je ontwikkeluren zijn je duurste uren
Elk uur dat een developer aan een intern CRM besteedt, is een uur dat niet naar je product of naar een klant gaat. De rekensom valt zelden in het voordeel van zelfbouw uit.
Automatisering in je eigen IT- of softwarebedrijf: de schoenmaker en zijn leest
Je adviseert klanten dagelijks over procesautomatisering, integraties en datakwaliteit.
Het probleem dat je bij je klanten feilloos herkent
En als je eerlijk bent: in je eigen bedrijf staat de pijplijn in een spreadsheet, komen supportvragen binnen op drie verschillende adressen, houdt iedere consultant zijn uren net iets anders bij, en weet niemand precies welke bugmelding van welke klant nu in welke sprint zit.
Dat is geen slordigheid. Het is een voorspelbaar patroon. IT- en softwarebedrijven bouwen liever dan dat ze kopen, declarabele uren gaan altijd vóór interne projecten, en het team bestaat uit mensen die prima met een omweg kunnen leven omdat ze technisch genoeg zijn om die omweg te overzien.
Tot het schaalt. Dan blijkt dat de kennis in hoofden zit in plaats van in systemen, dat je geen betrouwbaar beeld hebt van je marge per project, en dat je bij een due diligence of een ISO-audit niet kunt aantonen hoe je processen lopen.
Waarom je dit niet zelf moet bouwen
Dit is de eerste discussie die in elk softwarebedrijf opkomt: "dat bouwen we zelf wel even". Soms klopt dat. Meestal niet, en wel om drie redenen.
Zelf bouwen is logisch waar je iets unieks doet: een deel van je dienstverlening, een integratie die niemand anders heeft, een stuk product. Voor je eigen sales-, support- en projectketen is standaardsoftware vrijwel altijd sneller, goedkoper en beter onderhouden.
Intern gebouwde tools worden niet onderhouden
Ze krijgen prioriteit tot ze werken en daarna nooit meer. Twee jaar later draait er iets dat niemand meer durft aan te raken, gebouwd door iemand die inmiddels ergens anders werkt.
Je bouwt generieke functionaliteit na
SLA-bewaking, escalatiepaden, e-mailsynchronisatie, rapportage, rechten en logging zijn opgeloste problemen. Daar onderscheid je je niet mee, en je klanten betalen er niet voor.
De keten die je wilt sluiten: van lead tot renewal
Sales en pijplijn
Zoho CRM wordt de plek waar prospects, offertetrajecten, contracten en accounts samenkomen. Voor een IT-bedrijf zijn drie dingen daarin belangrijker dan gemiddeld: een offerteproces dat omgaat met zowel fixed price als nacalculatie, zicht op contractverlengingen en opzegtermijnen, en de koppeling tussen wat verkocht is en wat straks geleverd moet worden.
Een deal die je sluit is immers meteen een project of een implementatie, en die overdracht is precies waar in de praktijk beloftes verdwijnen.
Support die zich aan de SLA houdt
Zoho Desk vangt alle inkomende vragen op (mail, telefoon, chat, portaal) met SLA's per klant of contract, automatische routering, escalatie en prioritering.
Voor een softwarebedrijf is dat geen administratieve luxe: je hebt het contractueel vastgelegd en je moet het kunnen aantonen. Zonder ticketsysteem bestaat je SLA alleen op papier.
Daar horen twee dingen omheen die vaak worden vergeten
Een klantportaal dat eerstelijns werk overneemt
Technische klanten willen zelden bellen. Ze willen hun openstaande tickets zien, een nieuwe melding indienen met logbestanden erbij, de releasenotes lezen, hun licenties en verbruik controleren en hun facturen downloaden.
Een portaal dat dat biedt, verlaagt je ticketdruk en verhoogt tegelijk de tevredenheid: een zeldzame combinatie. Wat er bij de bouw van zo'n omgeving komt kijken lees je in ons artikel over klantportalen.
Marketing die aansluit op een lange salescyclus
Zoho Marketing Automation past bij hoe IT en software daadwerkelijk verkocht worden: lange trajecten, meerdere beslissers per account, en content die het zware werk doet.
Je scoort leads op functie en gedrag, voedt ze met cases, documentatie en webinars, en ziet welke accounts (niet welke individuen) zich oriënteren. Voor een SaaS-propositie komt daar het hele post-sale deel bij: onboarding, adoptie, upgrade-signalen en verlengingen.
Projecten en development: de twee snelheden in je bedrijf
Vrijwel elk IT- en softwarebedrijf draait twee soorten werk tegelijk, met een heel ander ritme.
Klantprojecten en implementaties
Zoho Projects is gemaakt voor werk met een opdrachtgever, een scope, een planning en een budget: implementaties, migraties, maatwerktrajecten en onderhoudscontracten. Je plant mijlpalen en afhankelijkheden, registreert uren per taak, bewaakt de voortgang tegen de begroting en geeft klanten gecontroleerd inzicht in de status.
De waarde zit hier vooral in twee cijfers die in veel IT-bedrijven ontbreken. Facturabiliteit per medewerker: hoeveel van de gewerkte uren komen daadwerkelijk op een factuur. En marge per project: wat je begrootte tegenover wat het werd, zodat je je volgende offerte op data baseert in plaats van op optimisme. Zonder urenregistratie die aan projecten en contracten hangt, blijven dat onderbuikgevoelens.
Productontwikkeling
Zoho Sprints is de agile kant: backlog, user stories, sprintplanning, scrumborden, velocity en releases. Het past bij teams die iteratief aan een eigen product werken, waar de scope beweegt en prioritering continu gebeurt.
Eerlijk daarbij: veel developmentteams zitten al in Jira, Azure DevOps of GitHub Projects en hebben daar goede redenen voor. Die overzetten is zelden de eerste winst die je wilt pakken. Wat je wél wilt is dat het systeem waar je developers in werken verbonden is met je supportomgeving, en dat kan via een koppeling net zo goed als via één platform.
De brug die bij de meeste bedrijven ontbreekt
Dit is het punt waar automatisering in een softwarebedrijf echt iets oplevert. Volg een bugmelding van begin tot eind:
Een klant meldt een probleem. Support beoordeelt het, reproduceert het en concludeert dat het een bug is. Die bug moet naar de backlog van development. Development pakt hem op in een sprint. De fix gaat mee in een release. En dan moet iemand de klant laten weten dat zijn probleem is opgelost.
-
Waar de keten breekt
In de meeste IT-bedrijven breekt die keten op minstens twee plekken. Support kopieert handmatig een ticket naar het devtool en verliest daarbij context. Of de fix wordt uitgeleverd en niemand koppelt terug, waardoor de klant drie weken later opnieuw belt over iets wat al opgelost is.
-
Een gesloten keten
Het ticket blijft gekoppeld aan het backlog-item, de status in development is zichtbaar vanuit support, bij een release worden automatisch alle gekoppelde tickets bijgewerkt en de betrokken klanten geïnformeerd. Je ziet bovendien welke klanten het meest geraakt worden door welke openstaande bugs: informatie die je prioritering een stuk minder gevoelig maakt voor wie het hardst roept.
Wat dit een IT- of softwarebedrijf concreet oplevert
Terugkerende omzet vraagt andere processen
Verschuif je van projecten naar abonnementen, dan verandert je hele procesinrichting mee. Bij projectomzet verdien je bij oplevering; bij terugkerende omzet verdien je pas na maanden, en verlies je alles bij opzegging.
Dat betekent dat een paar dingen die voorheen bijzaak waren, ineens kritisch zijn.
-
Onboarding bepaalt je churn
Een klant die in de eerste weken niet aan de praat komt, zegt binnen een jaar op. Onboarding hoort dus een proces te zijn met stappen, eigenaren en een meetbaar eindpunt, geen welkomstmail.
-
Adoptie is een vroegsignaal
Teruglopend gebruik, minder logins of een gebruiker die stopt met inloggen zijn maanden eerder zichtbaar dan een opzegging. Die signalen horen in je CRM te landen als taak voor een accountmanager.
-
Verlengingen zijn een proces, geen datum in iemands agenda
Met opzegtermijnen, contractwaarde en gebruikshistorie in één systeem bereid je een verlenginggesprek voor in plaats van dat je ermee overvallen wordt.
-
Support is een commerciële functie geworden
Bij abonnementen is de servicedesk het belangrijkste contactmoment dat je het hele jaar hebt. Wat daar gebeurt, bepaalt of de verlenging een formaliteit is of een onderhandeling.
Van supportticket naar ontwikkeltaak en weer terug naar de klant: de keten is eindelijk gesloten. Er valt niets meer tussen support en development in.
Hoe je dit invoert zonder je roadmap te gijzelen
-
Begin bij support, niet bij sales
Daar zit de meeste dagelijkse pijn, het effect is binnen weken zichtbaar en je raakt niemands heilige huisje.
-
Laat development voorlopig waar het zit
Bouw eerst de koppeling tussen support en het devtool dat je al gebruikt. Een migratie naar een ander backlogsysteem is een aparte beslissing met eigen weerstand.
-
Zet urenregistratie aan projecten en contracten vast
Voordat je met rapportage begint. Zonder die basis is elk dashboard fictie.
-
Vul de kennisbank vanuit je tickets
Maak het onderdeel van het afsluiten van een ticket, niet een los project waar nooit tijd voor is.
-
Open het portaal pas als er iets te zien valt
Een leeg klantportaal is slechtere service dan geen portaal.
-
Pak sales en marketing daarna op
Die profiteren van de klantdata die inmiddels betrouwbaar is.
-
Behandel het als een echt project
Een eigenaar, een planning en gereserveerde tijd. Interne trajecten die "ertussendoor" moeten, zijn de trajecten die nooit afkomen.
Begin bij je eigen keten
Het ongemakkelijke aan dit onderwerp is dat je de argumenten al kent. Je gebruikt ze zelf, elke week, bij klanten die hun processen niet op orde hebben. Het enige verschil is dat jouw interne project nooit een deadline en nooit een factuur heeft, en daarom eeuwig blijft liggen.
De keten is overzichtelijker dan hij lijkt: Zoho CRM voor pijplijn en contracten, Zoho Desk met Zoho Assist en Zoho Learn voor support, kennis en opleiding, een klantportaal voor selfservice, Zoho Projects voor klantprojecten en Zoho Sprints voor productontwikkeling, met Zoho Marketing Automation aan de voorkant. Niet omdat je alles tegelijk moet invoeren, maar omdat je dan één keer hoeft na te denken over waar welk gegeven thuishoort.
Veelgestelde vragen over automatisering in IT- en softwarebedrijven
-
Omdat je ontwikkeluren je duurste uren zijn en omdat SLA-bewaking, escalatiepaden, rechten, logging en rapportage opgeloste problemen zijn waar je je niet mee onderscheidt. Intern gebouwde tools krijgen bovendien prioriteit tot ze werken en daarna nooit meer. Zelf bouwen is wél logisch voor het deel dat uniek is aan jouw dienstverlening of product.
-
Niet per se, en meestal is dat niet de eerste stap. Wat je in elk geval wilt is dat support en development met elkaar verbonden zijn: een ticket dat gekoppeld blijft aan een backlog-item, zichtbare status vanuit support, en automatische terugkoppeling naar de klant bij een release. Dat kan via een koppeling met je bestaande devtool. Zoho Sprints is interessant als je toch al aan vervanging toe bent of als je de hele keten in één platform wilt hebben.
-
Zoho Projects is gemaakt voor werk met een opdrachtgever, een scope en een budget: implementaties, migraties en maatwerktrajecten, met mijlpalen, urenregistratie en budgetbewaking. Zoho Sprints is agile productontwikkeling: backlog, user stories, sprints, scrumborden en releases. Veel IT-bedrijven gebruiken beide naast elkaar, omdat klantprojecten en productontwikkeling nu eenmaal een ander ritme hebben.
-
Via de API's of standaardintegraties van beide systemen. Een supportmedewerker maakt vanuit het ticket een backlog-item aan, waarbij context, logbestanden en de getroffen klant meegaan. De statuswijziging in development is zichtbaar in het ticket, en bij een release worden gekoppelde tickets bijgewerkt en de betrokken klanten geïnformeerd. Die laatste stap wordt het vaakst overgeslagen en kost het meeste onnodige klantcontact.
-
Technische klanten gebruiken het graag, omdat ze liever zelf kijken dan bellen. Ze zien openstaande tickets, dienen meldingen in met bijlagen, lezen releasenotes, controleren licenties en verbruik en downloaden facturen. Dat verlaagt je eerstelijnsdruk en verhoogt tegelijk de tevredenheid. Voorwaarde is wel dat er iets te zien valt: een leeg portaal werkt averechts.
-
Door uren te registreren op project- en contractniveau en die te koppelen aan wat je hebt begroot en gefactureerd. Dan kun je sturen op twee cijfers: facturabiliteit per medewerker en marge per project. Zonder die basis baseer je elke volgende offerte op een inschatting in plaats van op wat vergelijkbare trajecten werkelijk kostten.
-
Een eerste stap (support met SLA's inrichten en koppelen aan je devtool) is doorgaans een traject van enkele weken. De volledige keten van marketing tot renewal bouw je gefaseerd op over een aantal maanden. De techniek is zelden de bottleneck; de bottleneck is interne tijd, omdat declarabel werk altijd voorgaat. Reserveer die tijd expliciet of het traject blijft liggen.
-
Drie dingen die direct tijd besparen: inkomende tickets classificeren, prioriteren en routeren zodat je engineers alleen de inhoudelijke gevallen zien; concept-antwoorden opstellen uit je eigen kennisbank en documentatie; en van opgeloste tickets automatisch kennisartikelen maken, zodat je kennisbank meegroeit zonder dat iemand daar apart tijd voor moet vrijmaken. AI agents werken daarbij binnen de rechten en kaders die je zelf instelt, en elke actie blijft herleidbaar.
Wil je weten waar bij jou de keten breekt?
Mobile XL is zelf een softwarebedrijf en kent deze discussies van binnenuit. We brengen je processen in kaart, bouwen de koppelingen met de tools die je wilt houden, en implementeren de rest.