Slik bygger du et internt verktøy: adminpaneler, godkjenninger og erstatning av regneark

For å bygge et internt verktøy velger du én arbeidsflyt som i dag er smertefull — vanligvis et delt regneark, en e-posttråd eller en chatkanal som gjør en databases jobb — og gjør den om til en liten app med et skikkelig skjema, en liste med statuser, riktige tilganger for hver rolle og en historikk over hvem som endret hva. En AI-appbygger kan lage en fungerende første versjon på en ettermiddag. Det som gjør at det lykkes, er å holde omfanget til én arbeidsflyt og bygge den sammen med folkene som bruker den hver dag.

Hva regnes som et internt verktøy

Interne verktøy er den lite glamorøse programvaren som driver en virksomhet. Vanlige typer:

For flere startpunkter, se ideer til interne verktøy for team.

Bør du i det hele tatt bygge det?

Behold regnearket hvis én person vedlikeholder det, dataene er små, og en feil koster lite. Bygg et verktøy når du legger merke til disse tegnene:

• Folk overskriver hverandres endringer, eller ingen vet hvilken kopi som er den gjeldende
• Du trenger at noen bare ser eller redigerer deler av dataene
• Du har skrevet en side med instruksjoner om hvordan arket brukes
• Statusendringer må varsle noen, og det blir stadig oversett
• Du trenger et revisjonsspor — hvem godkjente dette, og når

Det finnes også et mellomalternativ. Low-code-plattformer for interne verktøy (Retool, Airtable-grensesnitt, Softr og andre) gir deg byggeklosser oppå dataene dine. De passer når dataene dine allerede ligger i en støttet database eller et regneark, og du vil ha dra-og-slipp-skjermer. En AI-bygget app passer bedre når arbeidsflyten er spesifikk, du vil at den skal se ut og oppføre seg akkurat slik teamet ditt trenger, eller du vil eie koden. For det generelle spørsmålet, se bygge eller kjøpe programvare for en liten bedrift.

Design arbeidsflyten før skjermene

Skriv arbeidsflyten som en kort historie før du lager prompten. For et verktøy for utgiftsgodkjenning:

1. En ansatt sender inn en utgift: beløp, kategori, dato, beskrivelse, kvitteringsbilde.
2. Lederen varsles og godkjenner eller avviser med en kommentar.
3. Utgifter over en grense trenger også økonomiens godkjenning.
4. Økonomi merker godkjente utgifter som betalt i en ukentlig batch.
5. Alle kan se statusen til egne utgifter; økonomi ser alle.

Fra den historien får du:

• Data: utgifter, brukere, roller, godkjenninger (hvem, beslutning, kommentar, dato), vedlegg.
• Statuser: sendt inn → godkjent av leder → godkjent av økonomi → betalt, eller avvist.
• Roller: ansatt, leder, økonomi, admin.
• Regler: beløpsgrensen, og hvem som kan flytte et element til hver status.
• Skjermer: innsendingsskjema, «mine utgifter», «venter på min godkjenning», økonomiens tabell over alle utgifter, en detaljside med historikk.

Beskriv arbeidsflyten med disse begrepene, så kan AI-en bygge det riktige på første forsøk.

Tilganger og historikk

Interne verktøy holder ofte sensitive data — lønn, kundeopplysninger, penger. To regler:

1. Sjekk roller på serveren for hver handling. En leder skal ikke kunne godkjenne sin egen utgift ved å kalle godkjenningsendepunktet direkte.
2. Før historikk. Lagre hver statusendring og redigering med hvem som gjorde den og når. Det løser de fleste «hvem endret dette?»-diskusjoner og er uvurderlig når noe går galt.

Bestem hvordan folk logger inn. Innlogging med firmaets Google- eller Microsoft-kontoer er praktisk for team som allerede bruker dem; e-post og passord fungerer overalt. Uansett bør du begrense registrering slik at bare teamet ditt kommer inn.

En første prompt som fungerer

Bygg et internt verktøy for godkjenning av utgifter for et selskap med 25 ansatte. Ansatte sender inn en utgift med beløp, valuta, kategori (reise, måltider, programvare, utstyr, annet), dato, beskrivelse og et kvitteringsbilde. Lederen ser en liste «Venter på min godkjenning» og kan godkjenne eller avvise med en kommentar. Utgifter over 500 dollar krever deretter godkjenning fra noen med rollen Økonomi. Økonomi ser en tabell over alle utgifter med filtre etter status, person og måned, og kan merke godkjente utgifter som betalt. Hver statusendring registreres med hvem som gjorde den og når, vist som en tidslinje på utgiftssiden. Roller: ansatt, leder, økonomi, admin — sjekket på serveren for hver handling. Lagre alt i en database og legg inn realistiske eksempeldata. Enkelt, tett og raskt grensesnitt — dette er et arbeidsverktøy, ikke en markedsføringsside.

Byggesteg

1. Hovedtabellen og skjemaet for kjerneposten, med realistiske eksempeldata slik at søk og filtre tydelig fungerer.
2. Statuser og overganger, inkludert hvem som kan flytte et element til hver tilstand.
3. Roller og innlogging, begrenset til teamet ditt.
4. Historikkloggen på hver post.
5. Varsler — en e-post eller chatmelding når noe krever handling fra noen.
6. Importer eksisterende data fra regnearket. Slik gjør du et regneark om til en app forklarer rensing og import.
7. Pilot med to-tre ekte brukere i en uke før utrulling til alle.
8. Slå av den gamle prosessen på en fastsatt dato. To systemer som kjører side om side gjør at ingen av dem blir stolt på.

Få folk til å faktisk bruke det

Mange interne verktøy fungerer helt fint og feiler likevel, fordi folk fortsetter med den gamle måten.

• Bygg sammen med brukerne. Se noen utføre oppgaven i dag før du designer den nye versjonen.
• Gjør det raskere enn den gamle måten. Hvis innsending tar lengre tid enn å sende en melding, vil folk fortsette å sende meldinger.
• Tett er bedre enn pen. Operatører foretrekker tabeller med gode filtre og tastaturvennlige skjemaer fremfor store kort og mye luft.
• Sett neste handling først. «Venter på meg» bør være det første folk ser.

Vanlige feil

• Å bygge hele regnearket om. Flytt den ene smertefulle arbeidsflyten; la resten ligge i arket inntil videre.
• Ingen eier. Noen må ha ansvar for endringer og feilretting etter lansering.
• Tilganger som ettertanke. Å legge til roller i et ferdig verktøy er vanskeligere enn å starte med dem.
• Hoppe over revisjonssporet, og så trenge det første gang penger forsvinner.
• Publisere på en offentlig URL uten innlogging. Alt internt må kreve innlogging.

Holde det i gang etter lansering

En prosess endrer seg hver få måned — et nytt godkjenningssteg, en ny kategori, et nytt team. Planlegg for det fra starten:

• Behold innstillinger i tabeller, ikke i kode. Kategorier, grenser og godkjennertildelinger som lever i databasen kan endres av en admin uten ombygging.
• Samle forespørsler på ett sted. En enkel «foreslå en endring»-lenke i verktøyet slår forespørsler spredt over chatter.
• Eksporter regelmessig. En CSV-eksport av hovedtabellene betyr at dataene aldri blir fanget, og gjør månedsavslutning enklere.
• Test etter hver endring. Gå gjennom innsending, godkjenning og avvisning på nytt etter enhver endring i arbeidsflyten, fordi tilgangsfeil pleier å dukke opp der.

Driftskostnader

Et internt verktøy bygget med AI koster hosting, en database, fillagring hvis folk laster opp dokumenter, og muligens en e-post- eller meldingstjeneste for varsler. Det er vanligvis ingen lisens per sete for et verktøy du eier, noe som betyr noe når mange sporadiske brukere trenger tilgang. Den løpende kostnaden er noens tid til å vedlikeholde det.

Bygge det med Mythex

Interne verktøy passer godt for Mythex. Du beskriver arbeidsflyten, agenten bygger den i en live-forhåndsvisning, og legger til en Postgres-database for postene og fillagring for opplastinger som kvitteringer. Dokumentasjonens bruksområde for internt verktøy og bruksområde for adminpanel har startprompter. Kolleger kan hjelpe til med å bygge det i arbeidsområdet ditt uten lisens per sete.

To ting å vite. Innloggingene for teamet ditt som bruker verktøyet er en del av appen du bygger, med en tilnærming du velger — de er separate fra Mythex-kontoer. Og Mythex inkluderer ikke innebygde Salesforce-, HubSpot- eller Slack-integrasjoner for selve appen; de kobles til via API-ene deres med dine egne nøkler. Til en startprompt, prøv malene godkjenningssporing eller internt adminverktøy, og se slik bygger du et dashbord hvis det du egentlig trenger er mest diagrammer.

Spørsmål