Om te kunnen boeken bij sneleentaxi moet javascript aan staan.

De toolingkeuzes van sneleentaxi

Welke tooling hebben wij bij sneleentaxi gekozen en waarom?

Als boekingsplatform voor het boeken van taxi's hebben we met sneleentaxi.nl behoorlijk veel keuzes moeten maken op gebied van tooling. Er is tegenwoordig zoveel nieuwe software beschikbaar dat het maken van de juiste keuzes op dit gebied ingewikkelder is dan vroeger. Ik kan me herinneren dat ik in 1997 online ging met de website wievande4.nl (een soort kruising tussen het oude hotornot en hyves) - volledig gemaakt in ASP. Elke keer als wij een verandering bedachten, was deze vaak na een uurtje knutselen dezelfde dag online. We hadden wat backups van oude versies, maar dat was het dan ook wel zo'n beetje. Met 1 programmeur en een heel beperkte set van software was er op dat moment ook niet heel erg veel meer mogelijk. Pas 11 jaar later zou Github worden gelanceerd (2008).

De technologie is enorm veel verder. Maar met alle vooruitgang is het er echter niet eenvoudiger op geworden om een wat grotere applicatie zoals sneleentaxi in de lucht te houden. Het is het best te vergelijken met een oude televisie. Hij deed het altijd, je kon er destijds niet heel veel mee - maar we wisten niet beter. Tegenwoordig heb je twee of drie afstandsbedieningen nodig voordat je überhaupt beeld krijgt en vergt het continu updates om je tv werkend te houden. Vooruitgang is niet altijd eenvoudiger.

Om een inkijkje te geven in onze werkwijze, delen we hierbij onze keuze voor tooling. Ik kijk hierbij altijd naar drie factoren. Schaalbaarheid, deskundigheid en populariteit. Schaalbaar qua integraties en flexibiliteit bij verschil in wensen. Deskundig in de vorm van een goede helpdesk met medewerkers met een technologische achtergrond die makkelijk benaderbaar zijn. Populariteit in de vorm van een goede 'funding' en positieve opwaartse trend bij Google Trends - waardoor de community achter deze partijen de komende jaren waarschijnlijk wel de norm kan gaan worden. Tenslotte investeren wij ook vanuit onze kant veel tijd en geld in deze integraties en willen we niet geconfronteerd worden met een partij waar de stekker uit getrokken wordt, of waar doorontwikkeling niet hoog op hun agenda staat.

Wellicht is niet alle tooling die ik hier bespreek voor iedereen interessant. Misschien heb je momenteel één developer in dienst en nog geen heel team, of besteed je het development uit aan een extern bureau of een partij die dit vanuit het buitenland doet. Voor ons als platform is development een van de belangrijkste aspecten van ons bedrijf. Het heeft me enorm geholpen om me te verdiepen in de wereld van mijn CTO. Niet alleen begrijp ik daardoor veel beter zijn beweegredenen voor bepaalde keuzes, ook kan ik hem sneller overtuigen van strategische beslissingen die soms voorrang krijgen aan 'technische perfectie'. Het is een wisselwerking geworden. Ook hij kan mij overtuigen waarom we soms maanden werken aan het verbeteren van code, terwijl de reizigers of onze partners daar niet direct iets van merken.

Wanneer een development team uitbreidt, wordt het steeds lastiger om van iedereen bij te houden in welke bestanden men aan het werk is. Het tegelijkertijd werken aan verschillende projecten die toch met elkaar te maken hebben, kan conflicten veroorzaken. Om dit te voorkomen gebruiken we Git. Wij hosten al deze aanpassingen op Github. Teams kijken elkaars code na voordat deze 'gemerged' worden (en dus worden samengevoegd in de dan geldende versie). Daarna kan een klaargezette versie eventueel worden gepubliceerd op internet (deployment naar productie).

De toolingkeuzes van sneleentaxi

Voor het naar productie zetten gebruiken wij Buddy. Met behulp van deze tool kunnen we geautomatiseerd allerlei processen in gang zetten die zorgen dat we eigenlijk met één druk op de knop onze 'staging' versie naar een nieuwe 'productie' versie zetten. Deze processen zijn bijvoorbeeld het doen van allerlei automatische tests. Wanneer deze falen, gaat de productie niet door. Binnen Buddy heb je de mogelijkheden hier nog allerlei processen aan toe te voegen.

Om een roadmap te maken met technologische wensen gebruiken we in eerste instantie Trello. Deze wordt voornamelijk door management gevuld en zijn eigenlijk rauwe schetsjes van wensen die we netjes op basis van prioriteit kunnen indelen.

Pas later worden deze één voor één uitgewerkt in een briefing en mag het development team deze zelf verwerken in Jira (lijkt op Trello, maar dan veel uitgebreider en bij uitstek geschikt voor development). Hiervoor maken ze vooraf een inschatting van het te verwachten uren en kunnen deze daardoor goed in een sprint worden ingedeeld. Het aantal échte uren wordt bijgehouden in Toggl (ideaal om programmeurs en management inzicht te geven hoeveel uren werkzaamheden écht kosten) en is gekoppeld aan Jira. Hierdoor kunnen we achteraf ook beter evalueren mocht blijken dat projecten onverhoopt een grote uitloop hebben gehad. Alles is onderling ook met elkaar gekoppeld zodat we geen dubbel invoer werk hoeven doen.


De toolingkeuzes van sneleentaxi

Wanneer eenmaal alles op productie staat, treden er uiteraard altijd bugs op. Dit is inherent aan een site in ontwikkeling. Om deze goed te kunnen monitoren gebruiken we Bugsnag en Azure Application Insights. Hiermee zijn we in staat om direct in kaart te brengen welke bugs het meest voorkomen en ook wat voor metadata deze bugs met zich meebrengen (bijvoorbeeld wanneer een bug alleen voorkomt in een bepaalde browser, of op een bepaald tijdstip). Door de integratie van bugsnag hebben we enorm veel bugs (waar we niet altijd het bestaan van wisten) kunnen tackelen maar belangrijker is nog dat we inzicht hebben gekregen hoe urgent deze bugs waren. Soms kan het wijs zijn een bug te laten voor wat die is, bijvoorbeeld wanneer deze uitzonderlijk weinig voorkomt. Voor iemand van onze support afdeling kan het op dat moment super urgent lijken (reiziger kan niet boeken en belt in paniek op), maar wij kunnen nu met echte data precies vertellen dat een bepaalde uitzonderingssituatie slechts 3x per jaar voorkomt - waardoor we er bewust voor kiezen de bug niet op te lossen. Soms lost een bug zich na verloop van tijd ook zelf op door een nieuwe release die een bepaald stuk code overschrijft.

Rode draad door deze tooling is Slack. Wij gebruiken dit voor onze interne communicatie op kantoor. Ook belangrijke geautomatiseerde informatie wordt doorgegeven in kanalen waar we ons niet direct voor laten storen, maar we wel snel kunnen zien of er bijvoorbeeld een deployment geweest is, of dat een bug meer dan 30 keer op een dag is voorgekomen. Bepaalde triggers en alerts worden geautomatiseerd in kanalen getoond zodat we niet continu op allerlei sites hoeven in te loggen om deze informatie te vinden. Ook combineren we wat geautomatiseerde fun elementen aan Slack. Voor een boeking met een omzetrecord mogen we best even onze medewerkers storen.

Naast al deze interne 'tooling' hebben we ook bestaande integraties uitgebreid. Zo hebben wij op gebied van e-mailmarketing twee grote samenwerkingen. Voor de 'transactionele e-mails' (deze moeten aankomen, zoals bv bevestigingen en facturen) gebruiken wij Sendgrid. Deze partij stuurt voor ons alleen maar transactionele e-mails uit waarbij we inmiddels een dusdanig goede reputatiescore hebben opgebouwd dat deze de spambox eigenlijk niet meer weten te vinden. Dit heeft er natuurlijk alles mee te maken dat een bevestiging met daarin een voucher een 'open rate' heeft die natuurlijk veel hoger is dan bij een promotionele e-mail.

Uitgelichte Case; slimme integratie met ActiveCampaign zorgt voor geautomatiseerde personalisatie

De toolingkeuzes van sneleentaxi

Voor het versturen van marketing e-mails werken wij met ActiveCampaign. Vooral met deze laatste partner hebben wij onze integraties nu zo uitgebreid gemaakt dat we gebruik maken van vrijwel alle functies die dit pakket heeft.

Bij het doen van een boeking zenden we ActiveCampaign alle informatie die nodig is om geautomatiseerde mails te kunnen versturen. Klantprofielen worden opgeslagen (waarin wij zien hoeveel boekingen iemand doet, hoe vaak deze op de website komt en welke pagina's die bezoekt). We kunnen op basis van al deze variabelen op zoveel manieren geautomatiseerde mails versturen.

Voor minder druk bij support:

  • Mails aan reizigers (alleen vanaf de airport, andere type reizigers krijgen deze automation niet) waar alleen hun vluchtnummer ontbreekt in de boeking (het zou een conversiekiller zijn als we deze verplicht maken).

Voor upsells of heractivatie bij onze reizigers:

  • Mails versturen aan reizigers die slechts een enkele reis hebben geboekt naar Schiphol, waarvan wij het vermoeden hebben dat ze mogelijk nog vervoer op de terugweg nodig hebben.
  • Attenderen op prijswijzigingen in een bepaalde regio als wij hier gunstigere prijsafspraken hebben gesloten met vervoerders.
  • Kortingsvouchers aan bepaalde klantprofielen na enige tijd van inactiviteit, of juist enige tijd van actviteit met extra beloningen.

Voor het herkennen van business oppurtunities naar ons salesteam:

  • Het versturen van triggers aan ons salesteam als wij weten dat bedrijven boeken.
  • Het bijhouden van engagement scores om hen te vertellen hoe succesvol hun opvolging is. Dit zorgt ervoor dat sales niet bezig is met leads die minder geïnteresseerd zijn in onze follow-up.

Voor het herkennen van promotors:

  • Het versturen van 'hoe was je rit' beoordelingmails aan klanten die hun eerste ervaring met sneleentaxi hebben gehad (voorheen stuurden wij bijvoorbeeld mails na elke rit met deze vraag, tot ergenis van onze reizigers).
  • Het herkennen van gebruikers die ons een goede beoordeling hebben gegeven en ze wijzen op ons promotieprogramma waarin ze buren, vrienden en familie attenderen om ook van ons gebruik te maken.

Voor al deze scenario's zijn uitgebreide 'automations' opgezet die volledig geautomatiseerd hun werk doen. Naast deze voorbeelden zijn er nog tientallen andere situaties waarin we zorgen voor meer interactie met onze reizigers. Laat je niet ontmoedigen door de tijd die het kost om zo'n integratie op te zetten. Wij hebben er ongeveer 3 maanden werk aan gehad van één developer, uiteraard exclusief alle tijd voor het creëren van content en bedenken van alle scenario's. Uiteraard is het voor elke organisatie anders of zo'n diepe integratie de moeite waard van het ontwikkelen is (en volledig afhankelijk van marges per klant). Om toch een voorzichtig advies te geven zou ik zeggen dat het interessant wordt vanaf zo'n 15.000 e-mailadressen waarbij dit aantal wel blijft groeien en je een continue aanwas van nieuwe 'leden' hebt.

Conclusie

De belangrijke les is dat we het fijnst samenwerken bij bedrijven waar deskundige support beschikbaar is die ook makkelijk benaderbaar is. Het voorkomt onnodige uren van jouw kostbare tijd met het uitleggen van complexe situaties aan mensen die deze toch niet begrijpen. Deze voor ons harde voorwaarde, ontbreekt vaak bij de benchmarks op websites waarin ze software vergelijken.

En als laatste is mijn steevaste tip om te zien hoeveel integraties er mogelijk zijn (de basis is vaak een koppeling met Zapier waarmee we alvast op een 'plakband' manier kunnen testen of iets prettig werkt voordat wij onze developers de API's écht aan elkaar laten verbinden).

Wanneer je zelf juweeltjes qua tooling hebt ontdekt als online platform - reageer dan vooral. Liefst wel gewoon in de comments, dan kunnen anderen daar ook van meegenieten.