CRM of projectmanagementsoftware: heb je ze allebei nodig?

Bijna elk groeiend bedrijf stuit in dezelfde week op deze vraag. Iemand van sales vraagt om een plek om leads bij te houden. Iemand van de uitvoering vraagt om een plek om het werk bij te houden. En wie het budget beheert, kijkt naar beide verzoeken en stelt de volstrekt redelijke vraag: is dit niet twee keer dezelfde tool?

Dat is het niet. Maar het verschil is niet het verschil dat de meeste vergelijkingspagina's beschrijven. Het gaat niet over functies, en zeker niet over wie de mooiste kanbanborden heeft. Het gaat over hoe lang een record hoort te leven, en van wie het is als het huidige werk klaar is.

Dit artikel beantwoordt eerst de praktische vraag: heb je er twee nodig, en als je er maar één kiest, welke dan. Daarna komen de specifieke manieren aan bod waarop elke tool breekt zodra je hem het werk van de ander laat doen, en een derde opzet waardoor de keuze grotendeels vervalt.

Het korte antwoord, voor de details

Komen je klanten terug, dan heb je een CRM nodig. Heeft je werk meer dan drie stappen en meer dan één persoon, dan heb je projectmanagement nodig. De meeste bedrijven hebben uiteindelijk beide nodig, maar bijna niemand heeft beide op dag één nodig.

De volgorde telt zwaarder dan de keuze. Begin bij de kant van het bedrijf die nu geld kost. Een lead die nooit een tweede telefoontje kreeg, is een echt verlies dat je kunt benoemen. Een project dat twee weken te laat opleverde, is ook een echt verlies dat je kunt benoemen. Welke je het snelst benoemt, is de kant die je eerst oplost.

De fout is beide tegelijk kopen, voordat je weet hoe werk daadwerkelijk tussen de twee beweegt, en een half jaar later ontdekken dat dezelfde klant in twee systemen bestaat met twee verschillende telefoonnummers en dat niemand weet welk nummer klopt.

Waar een CRM eigenlijk voor is

Een CRM is een geheugensysteem voor relaties. Dat is het hele idee, en elke functie volgt daaruit.

De eenheid van een CRM is een persoon of een bedrijf, en de bepalende eigenschap is dat het record niet eindigt. Een contact dat je in je eerste maand toevoegde, is drie jaar later hetzelfde contact, met elk gesprek, elke offerte, elke klacht en elke verlenging die er tussenin zat. Niets aan dat record hoort gearchiveerd te worden als een bepaalde klus afloopt, want die klus is niet het punt. De persoon is het punt.

Wat dat geheugen je concreet oplevert:

• Context in het tweede gesprek. Je weet wat je offreerde, waar bezwaar tegen was en waar men uiteindelijk voor koos, zonder dat de klant het hoeft te herhalen.
• Een pijplijn die klopt met de werkelijkheid. Deals staan in fases met een waarde en een verwachte sluitingsdatum, dus je ziet volgende maand aankomen in plaats van achteraf.
• Eigenaarschap. Elke lead heeft een naam eraan hangen, het enige betrouwbare medicijn tegen de lead die niemand opvolgde omdat iedereen dacht dat een ander dat al deed.
• Verval signaleren. Omdat het CRM weet wanneer iets voor het laatst bewoog, kan het melden dat een deal al twee weken stil is. Een takenlijst kan dat niet, want een taak zonder datum is niet te laat, die ligt er gewoon.
• De reden van winst of verlies. Dit is het stuk dat vrijwel iedereen overslaat en precies het stuk dat de software terugverdient. Twintig verloren deals met een reden erbij zijn het goedkoopste marktonderzoek dat je ooit doet.

Wil je dieper op de basis in, dan gaat onze uitleg over wat een CRM is verder in op het recordmodel en op wat je van een eerste implementatie mag verwachten.

Waar projectmanagementsoftware eigenlijk voor is

Projectmanagementsoftware is een volgordesysteem. De eenheid is een stuk werk, en de bepalende eigenschap is precies het omgekeerde van die van het CRM: het record hoort te eindigen.

Een project bestaat om afgerond te worden. Zolang het loopt, is de waarde dat iedereen ziet wat er volgt, wat vastzit, wie welk stuk draagt en of het geheel op de toegezegde datum landt. Zodra het sluit, is de waarde bijna nul, en juist daarom archiveren deze tools netjes en heeft niemand daar moeite mee.

De concrete taken:

• Volgorde. Taak B kan niet starten voordat taak A klaar is, en de tool laat dat zien in plaats van het in iemands hoofd te laten zitten.
• Capaciteit. Wie heeft veertien openstaande items en wie drie. Dat is onzichtbaar tot het getoond wordt, en het is de belangrijkste reden dat werk stilletjes bij dezelfde twee mensen belandt.
• Het kritieke pad. Welke vertraging de opleverdatum echt verschuift en welke helemaal niets uitmaakt.
• Een gedeelde definitie van "klaar". De helft van de gemiste deadlines is onenigheid over wat klaar betekende, geen kwestie van inzet.
• Zichtbare blokkade. Een taak die negen dagen op een bestand van de klant wacht, hoort luid te zijn. In een takentool kan dat. In een spreadsheet nooit.

Zoek je een aparte tool voor deze kant, dan laat ons overzicht van projectmanagementsoftware zien waar de grote platforms in de praktijk verschillen.

Waar ze echt overlappen

De overlap is reëel, waardoor de verwarring redelijk is en niet naïef. Vier dingen komen in beide categorieën voor en zien er bijna identiek uit:

Borden en fases. Een als kanban getekende salespijplijn en een als kanban getekend project zijn visueel hetzelfde object. Kolommen, kaarten, slepen om vooruit te gaan. Deze oppervlakkige gelijkenis veroorzaakt het merendeel van de discussies in de trant van "waarom heb ik twee tools nodig".

Taken. Beide systemen hebben ze. Een CRM-taak is meestal een zetje aan een relatie: bel deze persoon terug, stuur de herziene offerte. Een projecttaak is een eenheid oplevering: bouw de pagina, controleer de tekst. Dezelfde vorm, ander gewicht.

Bestanden en notities. Beide bewaren documenten, beide bewaren reacties, en in beide gevallen hangt iemand ooit hetzelfde contract aan allebei.

Rapportage. Beide maken grafieken. Die van het CRM gaan over geld dat nog niet binnen is. Die van de projecttool gaan over tijd die al op is.

Door deze vier kan een klein team prima een tijdje de ene kant van het bedrijf in de tool van de andere kant draaien. De vraag is wat er bij groei breekt, en dat breekt op een voorspelbare manier.

Het faalpatroon: één tool dwingen het werk van de ander te doen

Hiervan bestaan twee versies, en ze falen op verschillende manieren.

Deals als kanbankaarten zonder historie

Dit is de meest voorkomende. Iemand bouwt een projectbord met de naam "Sales" en de kolommen Nieuw, Contact gehad, Offerte verstuurd, Onderhandeling en Gewonnen. Het is snel opgezet en het werkt echt een tijd, omdat het bord de enige vraag beantwoordt die je in het begin hebt: wat gebeurt er nu.

Het stopt met werken op de dag dat je het verleden nodig hebt. Een taakkaart houdt een actuele stand vast, geen reeks gebeurtenissen. Als een klant na elf maanden terugkomt en vraagt of de vorige offerte nog staat, heeft het bord geen antwoord: de kaart ging naar Gewonnen, werd met het bord gearchiveerd, en de offerte leefde in een mailwisseling die niemand terugvindt. Hetzelfde gat komt boven wanneer je wilt begrijpen waarom deals sneuvelen. Je hebt de uitkomst en geen enkele reden.

Er is nog een tweede, stillere prijs. Takenborden zijn niet gemaakt om volledig te zijn, maar om actueel te zijn, dus niemand valt over een kaart met een lege omschrijving. Een CRM-record met een lege omschrijving is een klant over wie je niets weet, en dat merkt niemand tot de persoon vertrekt die het wel wist.

Klanten bijgehouden in een takenlijst

De omgekeerde fout is subtieler. Hier gaat het CRM prima en leeft het uitvoeringswerk als CRM-taken die aan contacten hangen: "website bouwen voor Harper", "tweede correctieronde voor Harper", "eindoplevering voor Harper".

Aan een persoon gehangen heeft die lijst geen volgorde, geen afhankelijkheden en geen capaciteitsbeeld. Je ziet niet dat de tweede correctieronde niet kan starten voordat de klant feedback teruggeeft, en je ziet niet dat dezelfde ontwerper elf van dit soort items draagt bij negen klanten. Alles lijkt in orde tot precies de week waarin drie opleveringen botsen.

Het signaal is simpel. Betrap je jezelf erop dat je datums in taaktitels schrijft om te kunnen sorteren, dan ben je de takenlijst van het CRM ontgroeid en heb je echte volgordebepaling nodig.

De beslissende test: overleeft het record het werk?

Dit is de enige vraag die vrijwel elk geval beslecht. Pak een willekeurig record in je bedrijf en vraag: als dit werk klaar is, doet dit record er dan nog toe?

Zo ja, dan hoort het in een CRM. Een klant, een leverancier, een partner, een doorlopend account. Een klus afronden beëindigt de relatie niet, en het record archiveren kost je iets wat je later wilt hebben.

Zo nee, dan hoort het in projectmanagement. Een lancering, een bouw, een migratie, een campagne. Als het opgeleverd is, is de rol vervuld en is archiveren juist en geen verlies.

Draai deze test over alles wat je nu bijhoudt en je hebt binnen een minuut of tien een schone scheiding. Stel daarna de tweede vraag aan die scheiding: hoe vaak per maand moet er iets van de ene kant naar de andere? Elke gewonnen deal die een opgeleverd project wordt, is één oversteek. Elk opgeleverd project dat een verlenginggesprek oplevert, is er nog een. Tel de oversteken per maand. Dat getal zegt meer over de waarde van een verbonden opzet dan welke functielijst dan ook.

Verwante oefening: draai je al meer dan een handvol tools, dan bevat ons stuk over toolwildgroei bij kleine bedrijven een auditmethode om te tellen hoeveel sprongen één record door je hele stack maakt.

Draai je beide, dan is de overdracht het hele probleem

Genoeg bedrijven hebben terecht een apart CRM en een aparte projecttool nodig. Zeker in gespecialiseerde sectoren: vraagt je uitvoering om bouwplanning of om engineeringresourceplanning, dan haalt een algemene werkomgeving het niet bij een tool die daarvoor gebouwd is, en het heeft geen zin te doen alsof.

Maar als beide bestaan, draagt één moment vrijwel al het risico: de overgang van gewonnen deal naar lopend project.

In een opzet met twee tools is dat moment een mens die informatie overzet. Overgezet wordt wat in het projectsjabloon past; verloren gaat alles waar geen veld voor was: de korting die je gaf, de datum die je mondeling toezegde, het feit dat de klant een hekel heeft aan bellen, de reden dat hij voor jou koos en niet voor de goedkopere. De uitvoering start dan met een halve foto, en de klant ervaart dat als een bedrijf dat niet met zichzelf praat.

Drie dingen maken die overdracht overleefbaar:

1. Eén richting van waarheid. Het klantrecord leeft in één systeem en maar in één. Het andere houdt een verwijzing, nooit een kopie.
2. Een opgeschreven overdrachtspakket. Spreek de exacte lijst velden af die mee moeten, inclusief de zachte. Staan de toegezegde datum en de reden van de winst er niet op, dan reizen ze niet mee.
3. Iemand die eigenaar is van de oversteek. Automatisch of menselijk, maar met naam. Overdrachten die van "het team" zijn, gebeuren op de snelheid van niemand.

Bouw je dit zelf met koppelingen, reken dan op onderhoud. Synchronisaties breken stil, meestal na het hernoemen van een veld, en je hoort het doorgaans van een klant in plaats van van een melding.

Het derde antwoord: als de deal en zijn taken hetzelfde object zijn

Er is een manier om het overdrachtprobleem te laten verdwijnen in plaats van het te beheren, en die is het waard om te begrijpen, ook als je er uiteindelijk niet voor kiest: houd de relatie en het werk in dezelfde werkomgeving, op records die al van elkaar weten.

Daar is Zoye omheen gebouwd. Het is een AI-bedrijfsoperator en geen CRM of projecttool, en het praktische gevolg is dat een deal, het bijbehorende contact, de taken, de bestanden, de agenda-items en de facturen geen losse records in losse systemen zijn die gesynchroniseerd moeten worden. Het is één verbonden object, bekeken vanuit verschillende hoeken. Een deal op Gewonnen zetten vraagt van niemand om hem als project over te typen, want de taken hingen al aan de deal.

Taken op een bord, waarbij elke kaart nog steeds vastzit aan de deal en de klant waar hij uit voortkwam

Wat dat in het dagelijks gebruik verandert:

• Het kanbanbord voor de uitvoering en de pijplijn voor sales zijn verschillende weergaven op dezelfde verbonden gegevens, dus de historie van een klant en zijn lopende werk liggen één klik uit elkaar.
• Regels die je anders tussen twee tools zou moeten scripten, beschrijf je in één zin en bevestig je voordat ze draaien. Gewonnen deal die de onboardingtaken aanmaakt. Deal die zeven dagen stil is en zichzelf meldt. Te late factuur die zichzelf aanmaant. Elke run wordt gelogd en is omkeerbaar.
• Dezelfde assistent werkt in de webapp, op WhatsApp, via spraakbericht en in Slack, wat zwaarder telt dan het klinkt wanneer de persoon die weet wat er toegezegd is op locatie staat in plaats van achter een bureau.
• Records komen vandaan waar ze al staan. Bestaande projecten importeer je uit Trello, Jira, Notion, ClickUp, Monday.com of een spreadsheet, en de assistent haalt contacten uit een CSV, een pdf of een foto.

Eerlijk over de grenzen: dit vervangt geen gespecialiseerde planner, geen boekhoudgrootboek en geen ticketsuite voor support, en heeft je uitvoering er echt een nodig, houd die dan en koppel hem. De claim is smaller en nuttiger dan "vervangt alles". Hij luidt dat het klantrecord en het werk dat die klant bedient niet op twee plekken horen te leven, omdat juist de ruimte ertussen is waar dingen verdwijnen.

De prijzen staan volledig op de prijzenpagina als je ze naast een stack van twee tools wilt leggen.

Hoe je kiest, naar de vorm van je bedrijf

Eenmalig werk voor vreemden. Schoonmaak, losse klussen, eenmalige installaties. Eerst projectmanagement. De relatie herhaalt zich zelden, dus het CRM verdient minder terug. Houd een doorzoekbare contactlijst bij waar je over een jaar op terug kunt vallen.

Terugkerende klanten, eenvoudige uitvoering. Adviseurs, coaches, de meeste B2B-diensten. Eerst CRM. Het werk is een handvol stappen dat je in je hoofd houdt; de relatie is het kapitaal en die heeft geheugen nodig.

Terugkerende klanten, complexe uitvoering. Bureaus, studio's, systeemintegratoren. Je hebt beide nodig, dus de overdracht is je risico. Koppel ze fatsoenlijk of gebruik één werkomgeving waarin ze al verbonden zijn.

Lange verkooptrajecten, korte uitvoering. Bedrijfssoftware, kapitaalgoederen. Sterk CRM-zwaar. Het meeste waarde zit in het volgen van een gesprek van negen maanden met vijf betrokkenen.

Korte verkooptrajecten, lange uitvoering. Bouw, maatwerkproductie, grote projecten. Projectzwaar, met een licht CRM voor de pijplijn en voor de relatie na oplevering.

In welke groep je ook zit, aan het eind geldt dezelfde regel: koop voor het lek dat je kunt benoemen, niet voor het organogram dat je hoopt te krijgen.

Veelgestelde vragen

Tot slot

CRM en projectmanagement zijn geen concurrenten. Ze beantwoorden verschillende vragen over verschillende objecten met verschillende levensduur. Het CRM beantwoordt wie dit is en alles wat er met deze persoon gebeurd is. De projecttool beantwoordt wat er volgt en of het op tijd landt.

Waarschijnlijk heb je uiteindelijk beide nodig. Waar je je tegen moet verzetten, is de conclusie dat daaruit twee abonnementen en een koppeling ertussen volgen, want de koppeling is niet het moeilijke deel. Het moeilijke deel is dat een klant en het werk dat je voor hem doet hetzelfde verhaal zijn, en elke grens die je midden door dat verhaal trekt, kost je een stuk ervan.

Beslis met de overlevingstest van het record, koop voor het lek dat je kunt benoemen en houd de oversteek tussen sales en uitvoering zo kort mogelijk.

Verder lezen: wat een CRM werkelijk is, projectmanagementsoftware kiezen, de echte kosten van toolwildgroei en het volledige functiepakket in één werkomgeving.