Rapportage over meerdere objecten tegelijk

Het begint bijna altijd met een vraag in een managementoverleg. Iemand wil weten hoeveel contactmomenten er gemiddeld nodig zijn om een deal te winnen, uitgesplitst naar bedrijfsgrootte. De vraag is redelijk. De data is aanwezig. Toch komt er geen antwoord uit het systeem. Dat verdient uitleg.

Kern van het probleem

één object per rapport

Typische tussenoplossing

een export met formules

Dashboards

vanaf 1.500 euro

De vraag die niet past

Ontleed die vraag en je ziet drie objecten. Activiteiten leveren de contactmomenten. Deals leveren de uitkomst gewonnen of verloren. Organisaties leveren de bedrijfsgrootte. Het antwoord vraagt om een telling op activiteitniveau, gefilterd op de status van de bijbehorende deal, gegroepeerd op een veld van de bijbehorende organisatie.

In een rapportmodule die per rapport één hoofdobject kiest, valt die berekening tussen de stoelen. Kies je activiteiten, dan mis je de dealstatus als groepering. Kies je deals, dan kun je activiteiten niet tellen. Kies je organisaties, dan verlies je beide. De data is er, de rekenweg niet.

Wat cross-object betekent

Cross-object rapportage betekent dat een berekening de relaties tussen objecten volgt. Een activiteit hoort bij een deal, die deal hoort bij een organisatie, en die organisatie heeft een veld met het aantal medewerkers. Een cross-object rapport loopt die keten af en rekent op het niveau waar de vraag om vraagt.

Dat klinkt vanzelfsprekend en is het niet. Het vereist dat je vooraf weet hoe de objecten aan elkaar hangen, dus dat je datamodel klopt. Wie het datamodel niet op orde heeft, krijgt met een rapportagelaag geen antwoorden maar snellere onzin.

Waar de standaard stopt

De standaardrapporten van Pipedrive zijn goed in wat ze doen. Voortgang per fase, waarde per eigenaar, gewonnen tegenover verloren, activiteiten per gebruiker. Voor het dagelijkse sturen op de pipeline is dat ruim voldoende, en de opbouw daarvan staat bij dashboards en rapportages.

De grens ligt op vier plekken. Je kunt niet rekenen over twee objecten tegelijk. Je kunt historie van veldwijzigingen niet als reeks analyseren, dus je ziet de huidige stand en niet het verloop. Je kunt data uit andere systemen er niet naast leggen. En je kunt geen eigen berekening definiëren die als kolom terugkomt in elk rapport.

Elk van die vier is een bewuste keuze van het product. Een CRM hoort een CRM te zijn en geen analyseplatform. Het gevolg is alleen wel dat de vragen die ertoe doen buiten het systeem belanden, meestal in een spreadsheet die niemand durft te wijzigen.

Drie vragen doorgerekend

Neem drie vragen die in vrijwel elk salesoverleg langskomen. De getallen hieronder zijn rekenvoorbeelden, bedoeld om de mechaniek te laten zien.

Vraag één: hoeveel contactmomenten kost een gewonnen deal? Stel dat er in een kwartaal 40 deals zijn gewonnen en dat daar 520 afgeronde activiteiten aan hangen. Dat is 13 contactmomenten per gewonnen deal. Splits je dat naar bedrijfsgrootte, dan blijkt de ene groep op 8 uit te komen en de andere op 19. Dat verschil is stuurinformatie. Het gemiddelde van 13 is dat niet.

Vraag twee: welke bron levert niet de meeste, maar de beste leads?Kanaal A levert in dit voorbeeld 200 leads met een winratio van 4 procent. Kanaal B levert er 60 met een winratio van 15 procent. In aantallen wint A met 8 deals tegen 9 van B. In besteed uur wint B ruimschoots. Wie alleen op aantallen stuurt, investeert in het verkeerde kanaal. De rekenwijze achter dat percentage staat bij de winratio.

Vraag drie: waar stokt het proces echt? Een trechter van 100 naar 60 naar 45 naar 12 wijst de verliespost aan tussen de derde en de vierde fase. Zonder die uitsplitsing stuur je op de totale conversie van 12 procent en verander je willekeurig iets bovenin. De uitleg per fase staat bij conversieratio per fase.

Wat een eigen laag doet

Een rapportagelaag leest je Pipedrive-data, bewaart hem in een eigen model en rekent daar de vragen uit. Doordat de historie wordt bijgehouden, kun je verloop tonen in plaats van alleen de huidige stand. Doordat de objecten aan elkaar hangen, kun je over de keten heen rekenen. En doordat de definities op één plek staan, betekent winratio in elk rapport hetzelfde.

Die laatste eigenschap wordt onderschat. Het grootste rapportageprobleem in de meeste organisaties is niet het ontbreken van cijfers, maar het bestaan van drie versies van hetzelfde cijfer. Eén vastgelegde definitie maakt een overleg korter dan welk dashboard ook. Combineer dat met de doelstellingen uit doelen en forecasting en het gesprek gaat weer over de uitkomst.

Wanneer native genoeg is

Het eerlijke antwoord: vaker dan verkopers van dashboards toegeven. Blijven je vragen binnen één object, dan doen de standaardrapporten hun werk uitstekend en kost een extra laag je alleen onderhoud. Datzelfde geldt bij minder dan ongeveer tien gebruikers, waar het overzicht nog in het hoofd van de manager past.

Er is bovendien een volgorde. Een rapportagelaag op vervuilde data versnelt vooral het wantrouwen. Zorg dus eerst dat velden gevuld zijn en dat dubbelen weg zijn, zoals beschreven bij dubbele records opruimen. Pas als je vragen aantoonbaar over meerdere objecten gaan, over verloop in de tijd, of over data uit meerdere systemen, verdient een eigen laag zichzelf terug.

Veelgestelde vragen