Urenregistratie per klant voor softwarebureaus: zo houd je grip op facturatie
Elk bureau voert maandelijks hetzelfde gesprek: de uren in de registratie kloppen niet met het werk dat iedereen zich herinnert. De gebruikelijke conclusie is dat developers discipline missen. Die conclusie klopt niet, en ernaar handelen levert slechtere data op. Urenregistratie gaat structureel mis, en je kunt het structureel oplossen.
Waarom urenregistratie misgaat bij ontwikkelteams
Drie oorzaken verklaren vrijwel alles, en geen ervan is luiheid.
De urentool staat los van het werk
Als een uur schrijven betekent dat je een andere applicatie opent, de klant zoekt, het project zoekt en een omschrijving typt van iets dat je twintig minuten geleden afrondde, dan gebeurt het aan het eind van de dag uit het hoofd, of op vrijdag aan de hand van de agenda. Geheugen rondt naar beneden af, en doet dat consequent.
De eenheid van werk is niet de eenheid van factureren
Developers werken in tickets. Facturen gaan over projecten en contracten. Koppelt niets die twee, dan moet iemand aan het eind van de maand vertalen, en precies daar beginnen de discussies.
Klein werk is onzichtbaar
De fix van twaalf minuten, het belletje over een deployment, het "even kijken" naar een probleem op staging. Afzonderlijk verwaarloosbaar, samen het verschil tussen een rendabel contract en quitte spelen.
Regel 1: schrijf uren waar het werk gebeurt
De ingreep met de grootste hefboom is de timer op het ticket zetten. Niet in een aparte tool die 's nachts synchroniseert, maar op het record dat de developer toch al open heeft. Een lopende timer die hij start als hij het ticket oppakt, en een handmatige regel met notitie voor wat een timer niet vangt.
Daarmee wordt toewijzing ook automatisch: een regel op ticket #1035 weet al bij welk project en welke klant hij hoort, want het ticket weet dat. Niemand kiest een klant uit een lijst, dus niemand kiest de verkeerde. Zo werkt urenregistratie in Suporta, inclusief vanuit de Outlook-invoegtoepassing, zodat een supportgesprek vanuit de mailbox op hetzelfde ticket landt.
Regel 2: één regel context per urenregel
Een urenregel met "ontwikkeling, 3u" is onverdedigbaar zodra een klant ernaar vraagt. Een regel met "500-fout bij ongeldig e-mailadres gereproduceerd, regressietest toegevoegd, 1u20" doorstaat elke controle en kost negen seconden zolang het werk vers is.
Dat telt het zwaarst bij werk voor een vaste prijs, waar de klant niet per uur betaalt maar jij intern nog steeds moet weten of die vaste prijs klopte.
Regel 3: registreer ook niet-declarabele tijd
Bureaus vragen mensen vaak alleen declarabele uren te schrijven. Dat beschermt de factuur en vernietigt de stuurinformatie, want je verliest elk zicht op hoeveel niet-declarabel werk een klant veroorzaakt. Een contract met 30 gefactureerde uren en 15 uur onbetaalde afstemming is een ander bedrijf dan een contract met 30 gefactureerde en 2 onbetaalde uren, en een rapport dat alleen declarabele uren telt, ziet dat verschil niet.
| Categorie | Declarabel | Waarom registreren |
|---|---|---|
| Functionaliteit op een ticket | Meestal wel | De kern van de factuur |
| Bug in je eigen recente oplevering | Meestal niet | Meet herstelwerk, en dat is een kwaliteitssignaal |
| Supportgesprek of triage | Hangt van het contract af | Vaak de grootste verborgen kostenpost op een contract |
| Deployment en releasewerk | Vaak wel | Wordt vaker vergeten dan welke categorie ook |
| Intern overleg over de klant | Nee | Laat zien welke klanten duur zijn om te bedienen |
Regel 4: scheid "wij betalen" van "zij betalen"
Bureaus met zzp'ers of onderaannemers hebben twee afrekencycli over dezelfde uren: wat je de klant factureert, en wat de zzp'er jou factureert. Houd je dat bij met één vinkje, dan gebeurt een van twee dingen. Of een uur wordt met de zzp'er afgerekend en nooit doorbelast, of het wordt dubbel gefactureerd omdat een tweede export het opnieuw meenam.
Twee onafhankelijke statussen per regel — een klantfactuurstatus en een zzp-factuurstatus — haalt die hele foutcategorie weg. Het klinkt als een detail in het datamodel. Het is het verschil tussen je export vertrouwen en hem handmatig nalopen.
Hoe de maandafsluiting eruit hoort te zien
Een afsluiting in vijf stappen
- Nakijken, niet reconstruerenOpen de uren per klant over de periode. Alles is al toegewezen, dus dit is nakijken en geen onderzoek.
- Controleer de uitschietersRegels zonder notitie, verdacht ronde getallen, en tickets die ver over hun schatting gingen.
- Bepaal de coulanceSchrijf bewust af wat je wilt afschrijven, en leg vast dat je dat deed. Stille afboekingen leren je niets.
- Exporteren en facturerenMaak de factuurregels per klant en project, met je opslag waar die geldt, en markeer die regels daarna als gefactureerd.
- Kijk naar de verhoudingDeclarabel tegenover totaal, per klant. Dit is het getal dat aangeeft welk contract je opnieuw moet bespreken.
Een Excel-export blijft hier belangrijk, want financiële afdelingen draaien op spreadsheets en dat blijft zo. Het verschil is dat de spreadsheet een uitvoer van het systeem is en niet de plek waar de waarheid woont.
Waar AI-kosten in passen
Gebruik je AI-agents voor ontwikkelwerk, dan komt er naast de menselijke uren een tweede kostenpost per ticket bij. Behandel die hetzelfde: geboekt op het ticket, opgeteld per klant en project, en zichtbaar naast de uren als je factureert. Een ticket dat twee ontwikkeluren en een klein bedrag aan modelkosten opsoupeerde, hoort je beide getallen te geven. Zie AI-ontwikkelkosten per klant beheersen.
Een team zover krijgen dat het ook gebeurt
Wat werkt, op volgorde van effect
- check_circleMaak uren schrijven mogelijk zonder het ticket te verlaten. Al het andere is hieraan ondergeschikt.
- check_circleVraag om een notitie, geen verslag. Eén zin, geschreven terwijl het werk vers is.
- check_circleGebruik urendata nooit om developers publiek te vergelijken. Doe dat één keer en de datakwaliteit is voorgoed weg.
- check_circleLaat het team de rendementscijfers per klant zien die uit hun registratie komen, zodat het schrijven zichtbaar ergens toe dient.
- check_circleMaak het dagelijkse nakijken een gewoonte van twee minuten op een vast moment, in plaats van een reconstructie op vrijdag.
- check_circleRegistreer niet-declarabele tijd als volwaardige categorie, zodat niemand hoeft te verhullen waar de dag heen ging.
Het doel is geen perfecte urenstaat. Het doel is een urenstaat die nauwkeurig genoeg is om direct op te factureren, en volledig genoeg om te zien welke klanten de moeite waard zijn. Allebei haalbaar binnen een maand nadat de timer naast het werk is komen te staan.
Gerelateerde artikelen
Alle artikelen arrow_forward
Hoe softwarebureaus meerdere klanten beheren zonder een wildgroei aan tools
Het probleem is zelden het aantal tools. Het is dat elk systeem een andere versie van dezelfde klant bevat, en dat het gelijk houden daarvan een fulltimebaan is waar niemand voor is aangenomen.
De complete workflow voor softwarebureaus: ticket, sprint, development, testing en facturatie
Tien fasen, en de waarde zit in de koppelingen en niet in de fasen. Dit is het naslagwerk dat we zelf gebruiken, inclusief wat er bij elke overdracht misgaat en hoe je dat merkt.
Hoe beheer je AI-ontwikkelkosten per klant?
AI-kosten zijn niet duur door de tarieven. Ze zijn duur omdat ze onzichtbaar blijven tot de maandfactuur, en tegen die tijd horen ze bij niemand in het bijzonder.