RiverAIJeg har læst jeres kravspecifikation fra 25/4 grundigt. Det her er min plan for hele systemet, de steder hvor I skal vælge, hvad det koster, hvad det er værd, og hvor lang tid det tager. Så I kan vurdere mig på planen, ikke på et møde.
Jeres specifikation er god. Den siger præcis hvad I vil have, og det er sjældent. Derfor bruger jeg ikke pladsen på at gentage den. Jeg bruger den på de steder hvor jeg, som den der skal bygge det, ville være ekstra omhyggelig, og på hvordan jeg ville løse dem. Hvert sted får I min anbefaling og et alternativ, så valget er jeres.
Og ét princip går igen i hele systemet: alt ukendt stopper hos et menneske med en begrundelse. Fakturaer, betalinger og underleverandører styres aldrig af et gæt.
I skriver Zapier i specifikationen, og I skriver også at I selv skal kunne styre systemet bagefter. Det er det første valg, for det afgør både prisen i drift og hvor nemt det er at rette senere.
n8n er et automatiseringsværktøj med samme idé som Zapier, men det kan køre på en server I selv ejer. Selve softwaren er gratis at køre selv (n8n.io), serveren koster typisk få hundrede kroner om måneden (fx Hostinger KVM 2 til 14,99 dollar pr. måned efter introprisen, hostinger.com, august 2026). Jeg sætter server, n8n, backup og opdateringer op for jer og holder det kørende som en del af driftsaftalen. Serveren står i jeres navn. Stopper vi en dag, har I alt, og en anden kan tage over.
Velkendt og nemt at logge ind i. Prisen følger antallet af handlinger (Professional fra 19,99 dollar pr. måned for 750 handlinger, zapier.com/pricing, august 2026). Jeres vandfalds-SMS med ventetid og prioritering bliver mange små handlinger pr. sag, så regningen vokser med aktiviteten. Kan bygges, men jeg ville vælge det fra på grund af driftsprisen og fejlhåndteringen.
Begge priser er leverandørernes egne listepriser på det tidspunkt jeg skriver dette. De skal tjekkes igen når vi vælger.
Jeres idé er rigtig: kunden skal lande i den rigtige zone uden at nogen flytter rundt manuelt. Der er én praktisk ting at vide. Calendlys Routing Forms kan kun rute på et dropdown- eller radiosvar, ikke på et postnummer kunden selv taster (Calendlys egen guide til Routing Forms, og funktionen kræver Professional-plan eller højere). Så "postnummer ind, rigtig kalender ud" kræver et lille ekstra led.
Vi bygger en simpel side i jeres design. Kunden taster postnummer, siden slår zonen op i en tabel I selv kan rette (Nordsjælland om onsdagen osv.) og sender kunden videre til den rigtige Calendly-kalender. Ved booking opretter systemet leadet i Simply CRM og rækken i Logistik-arket automatisk.
Kunden vælger selv sit område i en liste. Ingen ekstra side, men kunden skal vide hvilket område de hører til, og zonerne kan ikke ændres uden at rette formularen.
e-conomic har et dokumenteret REST-API til kunder, kladdefakturaer, bogførte fakturaer og afsendelse (restdocs.e-conomic.com). Selve tilbudsdokumentet kan e-conomic lave, men "store knapper til Acceptér, Møde og Ret" er ikke noget e-conomics egen skabelon er bygget til. Derfor ville jeg lægge knapperne uden for e-conomic.
Tilbuddet vises på iPad'en på en side vi bygger, med de tre knapper. Tryk på Acceptér udløser resten automatisk: Rate 1 på 50 % oprettes og sendes fra e-conomic, kunden får velkomstmail eller SMS med link til den tekniske formular, og Logistik-arket opdateres. Møde og Ret lægger sagen tilbage til Julius med en note.
Kunden accepterer via e-conomics almindelige tilbudsmail. Det virker, men det giver ikke knapperne på iPad'en i rummet, og accepten kommer først når kunden reagerer hjemmefra.
Det sker i virkeligheden, og specifikationen siger ikke hvad der så skal ske. Mit forslag: Rate 1 er betaling for at sagen er sat i gang, så den bliver stående. Den nye dato skrives ind, Logistik-arket genberegner faserne (gulv, maler, rengøring), og underleverandørerne får en ny SMS. Aflyses sagen helt, laver systemet ikke selv en kreditnota. Den lander i en manuel kø hos jer med en begrundelse, for penge tilbage er altid en menneskebeslutning.
Her ligger den største daglige tidsbesparelse, og her er det vigtigt at bygge rigtigt. Jeg ville bruge en SMS-gateway der både kan sende og modtage svar til systemet (fx GatewayAPI, som har callbacks for både leveringsstatus og indkommende SMS). Så er kæden: Maler A får opgaven med et JA/NEJ-svar. Svarer A ja inden for 4 timer, er den booket. Svarer A nej, eller slet ikke, går opgaven til Maler B med det samme. Takker begge nej, stopper vandfaldet og Julius får besked med sagen markeret rødt i arket. Systemet booker aldrig nogen der ikke har sagt ja.
Et nej fra A sender straks videre til B. Tavshed sender videre efter 4 timer. Begge svar logges på sagen.
Der ventes altid 4 timer før B får besked, også når A har sagt nej efter to minutter. Enklere, men langsommere.
Specifikationen sender Rate 2 automatisk efter 8 dage. Men hvad med det ekstra der dukker op undervejs? Mit forslag: der findes ét sted at registrere ekstraarbejde på sagen (i arket eller i Simply CRM), og systemet lægger det med på Rate 2 som egne linjer. Rate 2 oprettes som kladde i e-conomic, og Julius godkender med ét klik før den sendes. Det koster jer tyve sekunder pr. sag og fjerner risikoen for en forkert faktura sendt automatisk.
Jeres regel er god: ingen Rate 2 hvis der står en reklamation over 2.500 kr i Simply CRM. Simply CRM har et web service-API med opslag, oprettelse og opdatering af poster (help.simply-crm.com, API-dokumentationen), så tjekket kan gøres automatisk på dag 8. Findes der en reklamation, stopper fakturaen i den manuelle kø med beløb og sag, og I beslutter.
AI-sekretæren skriver kladder i Gmail, I sender. Billedtjekket af håndværkernes billeder markerer det der ser forkert ud til et menneske, det godkender aldrig selv. Jeg lover ikke at en model finder alle fejl, det gør ingen leverandørs model i dag, men den kan fange det oplagte og spare jer for at kigge på alt. Persondata (fuldmagter, rapporter) holdes ude af det AI'en ser, og AI-leverandøren kører under databehandleraftale. I dag bruger jeg Anthropic (Claude) til den del.
Hver fase afsluttes med en test I selv kan se: vi kører en rigtig sag igennem, og fasen er først godkendt når den gør det I har bedt om. Tiden regnes fra første rate er betalt og adgangen til jeres systemer er bekræftet.
| Fase | Indhold | Uge | Testen I ser |
|---|---|---|---|
| 1 | Booking: postnummerside, Calendly-zoner, lead i Simply CRM, række i Logistik-arket, kundemappe i Drive | 1 til 2 | En testbooking ender det rigtige sted, alt er oprettet |
| 2 | Tilbud og økonomi: accept-side på iPad, Rate 1 fra e-conomic, velkomstmail/SMS, teknisk formular | 3 til 4 | Et accepteret tilbud giver faktura og mail uden at nogen rører noget |
| 3 | Logistik-motor: faseberegning i arket, vandfalds-SMS, farvekoder fra formular til arbejdsseddel, håndtering af flyttede bookinger | 5 til 6 | To rigtige underleverandører får SMS, et nej sender videre, begge nej stopper |
| 4 | Dokumenter: indflytningsrapporter, fuldmagter og farvekoder arkiveres på kundekortet i Simply CRM og i Drive | 7 | En sags dokumenter ligger det rigtige sted uden manuel flytning |
| 5 | Afslutning: reklamationstjek og Rate 2 som kladde til godkendelse, fraflytningsrapport og Trustpilot, AI-kladder i Gmail, billedtjek | 8 til 9 | En afsluttet sag kører hele vejen til Rate 2 med bremsen testet |
| 6 | Oplæring hos jer i Hellerup, dokumentation pr. flow, 30 dages support efter aflevering | 10 | I kan selv ændre zoner, underleverandører og tekster uden mig |
Kundeportalen (Softr eller en simpel side) er ikke med i de 10 uger og ikke i prisen. Jeg vil hellere bygge den når de første sager har kørt igennem, så vi ved hvad kunden faktisk har brug for at se. Den prissættes for sig.
I skriver selv at systemet skal frigøre cirka 40 timers manuel administration om ugen. Det tal har jeg ikke efterprøvet, det er jeres. Sætter vi en kontortime til 500 kr, ser regnestykket sådan her ud:
Hvorfor en driftsaftale med optimering og ikke kun drift: et system med så mange led (booking, CRM, e-conomic, SMS, underleverandører, AI) bliver aldrig færdigt den dag det afleveres. Jeres hverdag ændrer sig, en leverandør ændrer sit API, en ny type sag dukker op. De første måneder er dér hvor systemet lærer jeres virkelighed at kende, og det er billigere at justere løbende end at samle op i en ny byggeopgave. Vil I kun have drift uden optimering, kan det lade sig gøre for 2.500 kr pr. måned, men så betales justeringer pr. opgave.
Løbende omkostninger til jer selv: serveren (typisk få hundrede kroner om måneden), SMS-gateway (pr. SMS), Calendly Professional, og jeres eksisterende e-conomic og Simply CRM. Jeg tjener ikke på nogen af dem.
Jeg er Thomas Piper, RiverAI ApS, Fyn. Jeg bygger systemer der sidder inde i håndværksvirksomheders egne fagsystemer og kører hver dag. To af dem er i drift lige nu: ét klargør fakturakladder hver morgen ud fra sagerne, før kontoret møder. Et andet læser rekvisitioner i indbakken og opretter sagerne automatisk, med PDF og rekvisitionsnummer. Begge er bygget efter samme princip som her: AI skriver teksten, kode styrer tallene, og alt ukendt stopper hos et menneske med en begrundelse.
Ærligt om stakken: e-conomic og Simply CRM har jeg ikke bygget mod før. Begge har dokumenterede API'er (nævnt ovenfor), og det er regnet ind i tidsplanen. Jeg har bygget mod to andre danske fagsystemer med samme slags API og de samme faldgruber, og jeg ved hvor de plejer at gemme sig.
Efter mødet får I en opdateret version af denne plan med jeres valg skrevet ind, og en aftale I kan skrive under på. Forslag: torsdag 3. eller fredag 4. september, I vælger tidspunktet.
support@riverai.dk