Ja, je kunt een eigen applicatie binnen Pipedrive laten draaien, via een app-extensie die jouw pagina als paneel of venster in het CRM laadt. Zo bouwde Sales Surge voor Vita Brevis Fine Art een boekingstool. Het moeilijkste deel was niet de agenda maar de aanbetaling.

Een CRM als werkplek in plaats van adresboek
In de meeste Pipedrive-accounts staat het verslag van werk dat ergens anders gebeurde. Het gesprek vindt plaats in een telefoonsysteem, de boeking in een agenda en de betaling op een terminal of een betaalpagina. Pipedrive hoort het achteraf, als iemand eraan denkt.
Dat is te dragen zolang het werk langzaam is. Het loopt mis wanneer de hele transactie één telefoongesprek is, met een klant aan de lijn die een tijdslot wil. Elk extra venster is een plek om de draad kwijt te raken: een slot dat dertig seconden geleden nog vrij was, een kaartnummer dat twee keer is voorgelezen, een boeking die in het ene systeem bevestigd is en in het andere ontbreekt. Herken je dat uit je eigen telefoonwerk? Dan zit de winst niet in een betere inrichting maar in minder vensters.
Wat de boeker tijdens het gesprek nodig heeft op één scherm
De boeker blijft op het record waar hij al naar kijkt, kiest een slot in de studioruimtes en neemt daar de aanbetaling aan. Pipedrive is de werkplek, niet het verslag van de werkplek. Het oppervlak is bewust klein gehouden: studioruimtes, beschikbaarheid, een slot, een aanbetaling. Wat de boeker tijdens een gesprek nodig heeft staat op één scherm en niets anders. Een boekingstool die ook een planningssuite wil zijn wordt iets waar mensen doorheen klikken in plaats van iets dat ze gebruiken, en tijdens een lopend gesprek is dat verschil het hele product.
De tool: een eigen pagina binnen Pipedrive via een app-extensie
De tool laadt als iframe binnen Pipedrive. Pipedrive ondersteunt dat met app-extensies, en de verbinding terug loopt via dezelfde tokens en webhooks als elke andere koppeling. Het inbedden is de gewone kant van het werk. Wat een goede tool scheidt van een gevaarlijke, is niet dat hij in het CRM staat maar wat er gebeurt als een betaling niet schoon antwoordt.
De aanbetaling: goedgekeurd, geweigerd en onbekend
De aanbetaling gaat via een externe betaalverwerker en is een echte aanbetaling, geen testbedrag. Een kaart belasten lijkt het eenvoudige deel en op het gelukkige pad is dat het ook: verzoek sturen, goedkeuring krijgen, boeking bevestigen, verder praten. Het ontwerpprobleem zit in de derde uitkomst, die de meeste koppelingen niet eens modelleren. De tool kent drie uitkomsten en vouwt ze nooit samen tot twee.
| Uitkomst | Wat het betekent | Wat de tool doet |
|---|---|---|
| Goedgekeurd | Het geld is verplaatst. | De boeking wordt bevestigd. |
| Geweigerd | Een schone weigering. De verwerker antwoordde en het antwoord was nee. | De reservering blijft staan. De boeker kan een andere kaart proberen. |
| Onbekend | We kunnen niet zeggen of er geld is verplaatst. | Er wordt niets automatisch herhaald. Een mens controleert het. |
Waarom een timeout geen weigering is
De meeste betaalkoppelingen hebben twee uitkomsten, omdat ze geschreven zijn door iemand die een specificatie las waarin een timeout op een mislukking lijkt. Het is er geen. Een timeout betekent dat het verzoek mogelijk is ontvangen, verwerkt en afgeschreven, en alleen het antwoord onderweg zoekraakte. Dat onder “geweigerd” schuiven is geen vereenvoudiging maar een onwaar bericht over de rekening van de klant.
Wat dat kost als het misgaat is concreet. Wordt een timeout als weigering getoond, dan vertel je de boeker dat opnieuw afschrijven veilig is. In een telefoongesprek betekent een weigering: er is geen geld verplaatst, vraag om een andere kaart. Dus dat gebeurt. Is de eerste afschrijving wel doorgegaan, dan heeft de klant nu twee keer betaald en merkt dat later op een afschrift. Het kost de studio de afhandeling van een terugbetaling, mogelijk een terugboeking door de bank en het vertrouwen van iemand die midden in een aankoop zit.
Afdwingen op de server, niet alleen in het scherm
De scheiding wordt op de server afgedwongen. Staat een boeking in de onbekende toestand, dan wordt bevestigen geweigerd. Er is geen pad door het scherm waarmee het systeem alsnog tot een bevestiging te praten is. De bevestigingsstap vraagt naar de staat van de boeking en niet naar de staat van het scherm. Onbekend betekent nee.
De regel in één zin: als je niet kunt zeggen of het geld is verplaatst, kun je niet zeggen dat de boeking bevestigd is. Zeg het hardop, weiger de bevestiging en leg het voor aan een mens.
Wat we er bewust niet in bouwden
Er is geen automatische herhaalpoging, en dat is de bewuste beperking. Bij een onbekende uitkomst is een herhaling precies de dubbele afschrijving, uitgevoerd door software in plaats van door een mens, wat haar sneller en moeilijker op te merken maakt. Iemand moet naar die boekingen kijken. Dat is langzamer en het is juist.
De tool beperkt zich bovendien tot boeken en aanbetalen. Het is geen betaaldashboard, geen terugbetaalconsole en geen rapportagescherm. Terugbetalingen en afstemming blijven bij de betaalverwerker, waar het register staat van wat er werkelijk gebeurde. Elke functie die je toevoegt aan een tool die onder tijdsdruk wordt gebruikt, is iets meer om langs te scrollen.
Het boekingsprogramma is onderdeel van een groter traject
De boekingstool staat niet los. Bij Vita Brevis Fine Art stond voor de start een omgeving met meer dan 70 pijplijnen, die waren uitgesplitst per leadbron en per sessietype, met één gedeeld account en 129 automations die niemand had gedocumenteerd. In de eerste twee weken van het traject zijn de bestaande automations en pijplijnen in beeld gebracht. Daaruit volgde de keuze om niet op te schonen maar een nieuwe omgeving te bouwen, met drie pijplijnen en individuele accounts per medewerker.
De boekingstool werkt voor de vijf studio's van Vita Brevis Fine Art. Aanbetalingen lopen via Stripe en PayJunction, en klanten die willen spreiden kunnen Affirm kiezen. Elke betaaluitkomst wordt apart behandeld: goedgekeurd, geweigerd en onbekend lopen nooit door elkaar.
De planning liep over 22 weken, met een start op 24 april 2026 en een geplande einddatum van 26 september. Wij noemen dit project hier niet afgerond: de boekingstool is onderdeel van het traject, en onze laatste controle van de projectdocumentatie dateert van 11 september 2026. Training ter plaatse hoort bij het traject.

Wanneer configuratie niet genoeg is en bouwen wel past
Dit is het geval waar wij naar verwijzen als iemand vraagt of een Pipedrive-partner ook software hoort te bouwen. Vita Brevis had geen beter ingericht CRM nodig, maar een scherm dat nog niet bestond. Alleen configureren had een nette account opgeleverd en een boeker met vier tabbladen open.
Dat is de uitzondering en niet de regel. De meeste verzoeken die klinken als “dat moet maatwerk zijn” zijn te halen met inrichting, een bestaande app of een kant-en-klaar product. Een offerte waarin alles op maat gaat is zelfs een rode vlag, zie alles wordt maatwerk. Bouwen betekent ook onderhoud, en een eigen tool is iets waar je na de oplevering voor verantwoordelijk blijft. Vergelijk de opties in zelf bouwen of kant en klaar kopen en vraag wat een generalist of specialist hierover zegt bij CRM generalist of Pipedrive specialist. Twijfel je of een bestaande inrichting nog volstaat, dan helpt een second opinion op je inrichting.
Wat dit betekent voor een begeleid traject
Een begeleid traject is niet alleen configureren. Het gaat erom of je proces een scherm of een regel mist die de standaard niet levert, en of iemand dat tijdig ziet. Bij een partner die ook bouwt, hoort die vraag in de intake en niet halverwege de bouw. Wat een partner precies voor je doet en wat niet, staat bij wat een implementatiepartner doet.
Eerlijke grens: dit voorbeeld bewijst niet dat jouw proces een eigen tool nodig heeft. Het laat zien hoe wij ontwerpen wanneer dat wel zo is, en wat wij er bewust niet in zetten. Heb je een gesprek dat nu over drie vensters loopt, dan bespreken we graag of dat te bouwen is.