Apps en webapplicaties
Een boekingssysteem, een klantportaal, een intern hulpmiddel, een SaaS-product: software gebouwd rond het ene waarvoor mensen hem openen. In de browser als dat genoeg is, als native app voor iOS en Android als de telefoon het werk moet doen.
Een reservering aannemen op je eigen site in plaats van op een platform verandert twee dingen: de gast blijft van jou, en de commissie ook. Wat er geregeld moet worden is altijd hetzelfde korte lijstje. Wat er te boeken valt, en in welke eenheid: kamers, tafels, stoelen, tijdsloten of een gids. Welke overlap verboden is, zodat twee mensen niet in dezelfde seconde hetzelfde moment pakken. Of de gast nu betaalt, een aanbetaling doet of achteraf afrekent. Wat er in de bevestiging en de herinnering staat. En wat de mensen achter de balie zien als iemand belt om het te verzetten.
Dat lijstje leest per bedrijf anders. Een hotel of een B&B boekt nachten en bezetting. Een theater of een evenement boekt stoelen tegen een capaciteit per voorstelling. Een restaurant boekt tafels per tijdslot, een touroperator boekt gidsen en vertrektijden. Wij bouwen de versie die jouw zaak echt nodig heeft, gekoppeld aan de boekingstool die je al draait of als een eigen reserveringssysteem, en we zeggen welke van die twee bij jou het goedkoopste antwoord is.
Het meeste zoeken hierop eindigt bij een kant-en-klaar boekingsprogramma, en voor een hoop bedrijven is dat ook de juiste aankoop: dekt een standaardtool je agenda, je betalingen en je uitzonderingen, dan is kopen goedkoper dan bouwen, en dat zeggen we in het eerste gesprek. Waar wij het natuurlijke antwoord op zijn, is de andere helft van de vraag: een website met reserveringssysteem erin, waar boeken onderdeel van de site is in plaats van een link naar de pagina van iemand anders. Dat is een boekingsmodule op je eigen domein, in je eigen ontwerp, met je eigen bevestigingsmail. En het wordt een reserveringssysteem op maat zodra de standaardstroom echt niet past: meerdere locaties, medewerkers of middelen tegelijk, regels die per seizoen veranderen, of een boeking die moet landen in het systeem waar je kantoor al in werkt.
Een webapplicatie die je met een abonnement verkoopt is een ander karwei dan een die je zelf intern gebruikt: accounts en rollen, een abonnement en een betaling die doorloopt, een factuurspoor waar je boekhouder mee uit de voeten kan, en een eerste versie die smal genoeg is om echte gebruikers te bereiken voordat de roadmap het budget opeet. Wij bouwen de kleinste versie waar iemand daadwerkelijk voor zou betalen, in je eigen accounts en op je eigen naam, en het product blijft van jou.
Een maatwerk webapplicatie is maar een deel van de tijd het juiste antwoord. Doet een bestaande tool met een paar koppelingen hetzelfde werk, dan zeggen we dat in het eerste gesprek, want dat is goedkoper voor jou en het houdt het project dat we wél aannemen eerlijk.
Hoe we werken
Stap 01 · Afbakenen
Wat de applicatie perfect moet doen, wie hem gebruikt, of hij in de browser of op de telefoon leeft, en wat buiten versie één blijft. Een kleine, scherpe eerste release wint van een grote vage.
Stap 02 · Ontwikkelen
Eerst gebruikersstromen en klikbare prototypes, dan interface en code: een webapplicatie onder je eigen domein, of iOS en Android, met de koppelingen naar de systemen die je al draait, zoals agenda, betalingen, CRM en boekhouding.
Stap 03 · Uitbrengen
Testen met echte gebruikers en op echte toestellen, live onder je eigen domein of via de App Store en Google Play, en een plan voor de versies na de eerste.
Een app verdient zijn plek door morgen weer geopend te worden.
In de browser volgt hij het web, op de telefoon iOS en Android, dus niemand hoeft hem te leren.
Getest met echte gebruikers en op echte toestellen voordat hij live gaat, niet erna.
Zo opgezet dat versie twee voortbouwt op één, zonder opnieuw te beginnen.
Een webapplicatie als mensen hem aan een bureau gebruiken of af en toe op de telefoon, en als hij via een URL gevonden en gedeeld moet worden. Een native app als mensen één taak vaak op de telefoon doen, hem offline nodig hebben, of camera, locatie of meldingen gebruiken. We zeggen je welke van de twee het is, en soms is het antwoord een goede mobiele website. Bekijk webdesign
Ja. Er zijn drie routes: een bestaande boekingstool koppelen, een boekingsstroom op je eigen site bouwen, of doorverwijzen naar een platform. Welke past hangt af van je agenda, je betalingen en het aantal uitzonderingen. Een boekingsstroom die wij bouwen dekt meestal meerdere locaties of medewerkers, betalen op het moment van boeken, bevestigingen en herinneringen per e-mail, en een overzicht voor de mensen achter de balie; Roosty in ons AI Lab is dezelfde gedachte verder doorgetrokken, als weekbord voor horecazaken. Ons artikel over boekingssystemen loopt alle drie de routes langs. Lees over boekingssystemen
Het moment wordt vastgehouden zodra iemand aan de boeking begint en weer vrijgegeven als die boeking niet wordt afgemaakt, en de beschikbaarheidscheck draait op de server, niet in de browser. Dat is de saaie helft van een reserveringssysteem, en precies de helft die bepaalt of je personeel het vertrouwt.
Allebei, en het mag per soort boeking verschillen: het hele bedrag, een aanbetaling op het moment van reserveren, of niets tot ze er zijn. Wat je kiest hangt vooral af van hoe vaak mensen niet komen opdagen en hoe makkelijk je een leeg moment nog vult.
Dat hangt af van het aantal stromen in de eerste versie, de systemen waarmee hij koppelt en of hij uitkomt in de browser, op beide telefoonplatforms of alle drie. Afbakenen is precies daarom de eerste stap. Ons artikel over webapps legt uit wat de kosten en de terugverdientijd bepaalt. Lees over webapps en terugverdientijd
Of je nu een webapplicatie laat maken of laat ontwikkelen, de planning wordt bepaald door de omvang en niet door ons. Wat eraan trekt: het aantal stromen in de eerste versie, met hoeveel systemen hij moet praten, of hij alleen in de browser uitkomt of ook via de App Store en Google Play, en hoe snel beslissingen en inhoud van jouw kant terugkomen. We spreken de omvang en de planning samen af na het eerste gesprek, en we noemen liever een datum die we halen dan een datum die op maandag goed klinkt.
De applicaties die we kunnen laten zien draaien in ons AI Lab: Roosty, een personeelsplanbord voor horecazaken, en Kassabon.ai, een assistent voor bonnen en garantie, beide live producten met een eigen casepagina daar. In deze studio laat de aanvraagstroom op Solara Red Sea Tours dezelfde aanpak zien op een website. Bekijk Solara Red Sea Tours
Jij. Een webapplicatie draait onder je eigen domein en accounts; een native app verschijnt onder je eigen developeraccounts. We richten ze samen in en begeleiden de beoordeling.
Vertel wat je wilt bouwen. We denken mee over de aanpak, zeggen eerlijk wat het vraagt en komen terug met een duidelijke volgende stap.
