Een interne tool bouwen: beheerpanelen, goedkeuringen en vervanging van spreadsheets
Om een interne tool te bouwen kies je één workflow die nu pijnlijk is, meestal een gedeeld spreadsheet, een e-mailketting of een chatkanaal die het werk van een database doen, en maak je daar een kleine app van met een goed formulier, een lijst met statussen, de juiste rechten per rol en een geschiedenis van wie wat heeft gewijzigd. Een AI-appbouwer kan in een middag een werkende eerste versie maken. Wat het laat slagen is de scope beperken tot één workflow en bouwen met de mensen die de tool elke dag gebruiken.
Wat telt als interne tool
Interne tools zijn de onopvallende software die een bedrijf draaiende houdt. Veelvoorkomende types:
| Type | Wat het doet | Vervangt |
|---|---|---|
| Beheerpaneel | Zoeken, bekijken en bewerken van records (klanten, bestellingen, gebruikers) | Directe databasewijzigingen, een enorm spreadsheet |
| Aanvraag- en goedkeuringsflow | Iemand dient in; iemand anders keurt goed of wijst af | E-mailkettingen, “kun je dit even goedkeuren?”-berichten |
| Tracker | Items die door fases gaan (aanwervingen, middelen, bugs, leveringen) | Een blad met een gekleurde statuskolom |
| Checklist- of onboardingtool | Verplichte stappen met eigenaren en deadlines | Een gekopieerd document per nieuwe medewerker of klant |
| Operationeel dashboard | Actuele cijfers en uitzonderingen op één pagina | Het wekelijkse overzicht dat iemand met de hand maakt |
Voor meer startpunten, zie ideeën voor interne tools voor teams.
Moet je het überhaupt bouwen?
Houd het spreadsheet als één persoon het onderhoudt, de gegevens beperkt zijn en een fout weinig kost. Bouw een tool wanneer je deze signalen ziet:
- Mensen overschrijven elkaars wijzigingen, of niemand weet welke kopie actueel is
- Je moet sommige mensen alleen een deel van de gegevens laten zien of bewerken
- Je hebt een pagina instructies geschreven over hoe het blad werkt
- Statuswijzigingen moeten iemand informeren, en dat wordt steeds gemist
- Je hebt een auditspoor nodig: wie heeft dit goedgekeurd, en wanneer
Er is ook een middenweg. Low-code-platforms voor interne tools (Retool, Airtable-interfaces, Softr en andere) geven je bouwstenen bovenop je gegevens. Ze passen goed wanneer je gegevens al in een ondersteunde database of spreadsheet staan en je drag-and-drop-schermen wilt. Een door AI gebouwde app past beter wanneer de workflow specifiek is, je wilt dat hij precies werkt zoals je team dat nodig heeft, of je de code zelf wilt bezitten. Voor de algemene vraag, zie zelf bouwen of kopen voor een klein bedrijf.
Ontwerp de workflow voordat je de schermen ontwerpt
Schrijf de workflow als een kort verhaal voordat je een prompt maakt. Voor een onkostengoedkeuringstool:
- Een medewerker dient een uitgave in: bedrag, categorie, datum, omschrijving, foto van het bonnetje.
- Hun manager krijgt een melding en keurt goed of wijst af met een opmerking.
- Uitgaven boven een limiet hebben ook goedkeuring van financiën nodig.
- Financiën markeert goedgekeurde uitgaven wekelijks in een batch als betaald.
- Iedereen kan de status van de eigen uitgaven zien; financiën ziet alles.
Uit dat verhaal volgt:
- Gegevens: uitgaven, gebruikers, rollen, goedkeuringen (wie, besluit, opmerking, datum), bijlagen.
- Statussen: ingediend → goedgekeurd door manager → goedgekeurd door financiën → betaald, of afgewezen.
- Rollen: medewerker, manager, financiën, beheerder.
- Regels: de bedragdrempel, wie een item naar elke status mag verplaatsen.
- Schermen: indienformulier, “mijn uitgaven”, “wacht op mijn goedkeuring”, de tabel met alle uitgaven voor financiën, een detailpagina met geschiedenis.
Beschrijf de workflow op die manier en de AI kan het juiste bouwen bij de eerste poging.
Rechten en geschiedenis
Interne tools bevatten vaak gevoelige gegevens: salarissen, klantgegevens, geld. Twee regels:
- Controleer rollen op de server bij elke handeling. Een manager mag zijn eigen uitgave niet kunnen goedkeuren door het goedkeuringseindpunt rechtstreeks aan te roepen.
- Registreer de geschiedenis. Sla elke statuswijziging en bewerking op met wie die deed en wanneer. Dat beslecht de meeste discussies over “wie heeft dit gewijzigd?” en is onmisbaar wanneer er iets misgaat.
Bepaal hoe mensen inloggen. Inloggen met het Google- of Microsoft-account van je bedrijf is handig voor teams die die al gebruiken; e-mail en wachtwoord werkt overal. Beperk in beide gevallen de registratie zodat alleen je team toegang krijgt.
Een eerste prompt die werkt
Bouw een interne onkostengoedkeuringstool voor een bedrijf met 25 medewerkers. Medewerkers dienen een uitgave in met bedrag, valuta, categorie (reizen, maaltijden, software, apparatuur, overig), datum, omschrijving en een upload van een foto van het bonnetje. Hun manager ziet een lijst “Wacht op mijn goedkeuring” en kan goedkeuren of afwijzen met een opmerking. Uitgaven boven 500 dollar hebben daarna ook goedkeuring nodig van iemand met de rol Financiën. Financiën ziet een tabel met alle uitgaven, met filters op status, persoon en maand, en kan goedgekeurde uitgaven als betaald markeren. Elke statuswijziging wordt geregistreerd met wie het deed en wanneer, zichtbaar als tijdlijn op de uitgavenpagina. Rollen: medewerker, manager, financiën, beheerder, op de server gecontroleerd bij elke handeling. Alles opslaan in een database en realistische voorbeeldgegevens toevoegen. Strakke, dichte, snelle interface; dit is een werktool, geen marketingsite.
Bouwstappen
- De hoofdtabel en het formulier voor het kernrecord, met realistische voorbeeldgegevens zodat zoeken en filters duidelijk werken.
- Statussen en overgangen, inclusief wie een item naar elke toestand mag verplaatsen.
- Rollen en inloggen, beperkt tot je team.
- Geschiedenislogboek bij elk record.
- Meldingen: een e-mail of chatbericht wanneer iets actie van iemand vraagt.
- Bestaande gegevens importeren uit het spreadsheet. Een spreadsheet omzetten naar een app behandelt opschonen en importeren.
- Pilot met twee of drie echte gebruikers gedurende een week voordat je het voor iedereen uitrolt.
- Schakel het oude proces uit op een vaste datum. Twee systemen naast elkaar betekent dat geen van beide wordt vertrouwd.
Zorgen dat mensen het ook echt gebruiken
Veel interne tools werken perfect en mislukken toch, omdat mensen de oude werkwijze blijven gebruiken.
- Bouw samen met de gebruikers. Kijk hoe iemand de taak vandaag uitvoert voordat je de nieuwe versie ontwerpt.
- Maak het sneller dan de oude manier. Als indienen langer duurt dan een bericht sturen, blijven mensen berichten sturen.
- Dicht gaat voor mooi. Operators geven de voorkeur aan tabellen met goede filters en toetsenbordvriendelijke formulieren boven grote kaarten en witruimte.
- Zet de volgende actie vooraan. “Wacht op mij” moet het eerste zijn wat mensen zien.
Veelgemaakte fouten
- Het hele spreadsheet nabouwen. Verplaats de ene pijnlijke workflow; laat de rest voorlopig in het blad staan.
- Geen eigenaar. Iemand moet verantwoordelijk zijn voor wijzigingen en reparaties na de lancering.
- Rechten als bijzaak. Rollen achteraf toevoegen aan een afgeronde tool is moeilijker dan ermee beginnen.
- Het auditspoor overslaan, en het dan nodig hebben de eerste keer dat er geld verdwijnt.
- Publiceren op een openbare URL zonder inlog. Alles wat intern is moet inloggen vereisen.
Na de lancering draaiende houden
Een proces verandert elke paar maanden: een nieuwe goedkeuringsstap, een nieuwe categorie, een nieuw team. Houd daar vanaf het begin rekening mee:
- Bewaar instellingen in tabellen, niet in code. Categorieën, drempels en goedkeurders die in de database staan, kan een beheerder wijzigen zonder herbouw.
- Verzamel verzoeken op één plek. Een eenvoudige link “stel een wijziging voor” in de tool werkt beter dan verzoeken die verspreid staan over chats.
- Exporteer regelmatig. Een csv-export van de belangrijkste tabellen zorgt dat de gegevens nooit vastzitten en maakt maandafsluiting eenvoudiger.
- Test na elke wijziging. Loop na elke aanpassing aan de workflow opnieuw door indienen, goedkeuren en afwijzen, want rechtenfouten duiken daar vaak op.
Kosten
Een met AI gebouwde interne tool kost hosting, een database, bestandsopslag als mensen documenten uploaden, en mogelijk een e-mail- of berichtendienst voor meldingen. Voor een tool die je bezit zijn er meestal geen licenties per gebruiker, wat belangrijk is wanneer veel incidentele gebruikers toegang nodig hebben. De doorlopende kosten zijn de tijd van iemand om de tool te onderhouden.
Bouwen met Mythex
Interne tools passen goed bij Mythex. Je beschrijft de workflow, de agent bouwt hem in een live preview, voegt een Postgres-database toe voor de records en bestandsopslag voor uploads zoals bonnetjes. De documentatie bevat de use case voor interne tools en de use case voor beheerpanelen met startprompts. Collega's kunnen meehelpen bouwen in je werkruimte, zonder kosten per zetel.
Twee dingen om te weten. Het inloggen voor je team dat de tool gebruikt is onderdeel van de app die je bouwt, met een aanpak die jij kiest; het staat los van Mythex-accounts. En Mythex heeft geen ingebouwde Salesforce-, HubSpot- of Slack-koppelingen voor de app zelf; die verbind je via hun API's met je eigen sleutels. Voor een startprompt kun je de sjablonen goedkeuringstracker of interne beheertool proberen, en lees hoe je een dashboard bouwt als je vooral grafieken nodig hebt.
Veelgestelde vragen
Wat is een interne tool?
Een interne tool is software die je eigen team gebruikt om het bedrijf te runnen, en niet iets wat klanten zien: een beheerpaneel, een goedkeuringsflow, een tracker, een operationeel dashboard. De meeste beginnen als spreadsheet of inbox die lastig beheersbaar is geworden.
Wanneer moet ik een spreadsheet vervangen door een interne tool?
Wanneer meerdere mensen het bewerken en elkaars wijzigingen overschrijven, wanneer je wilt bepalen wie wat mag wijzigen, wanneer je steeds instructies moet schrijven over hoe het blad werkt, of wanneer fouten erin echt geld kosten. Als één persoon het beheert en fouten weinig kosten, houd dan het spreadsheet.
Kan ik interne tools bouwen zonder ontwikkelaar?
Ja. AI-appbouwers en low-code-platforms voor interne tools laten niet-ontwikkelaars werkende beheerpanelen, trackers en goedkeuringsflows bouwen. Regel wel dat iemand de tool daarna beheert, want processen veranderen en de tool moet mee veranderen.
Hoe bepaal ik wie wat mag doen in een interne tool?
Geef elke gebruiker een rol, zoals aanvrager, goedkeurder of beheerder, en controleer die rol op de server bij elke handeling, niet alleen door knoppen te verbergen. Houd een logboek bij van wie wat en wanneer heeft gewijzigd, zodat fouten te herleiden zijn.