Kunde-case: Engestofte Gods

Om Engestofte Gods

#

Engestofte Gods er et gods beliggende i Maribo på Lolland — en historisk ejendom med rødderne dybt plantet i dansk godskultur. Ejendommen rummer bl.a. historiske stalde, lader og en gårdsplads, som hvert år i starten af december danner rammen om et af årets hyggeligste lokale arrangementer: et julemarked.

I 2026 løber julemarkedet af stablen den 5.–6. december, kl. 10–16. Der er plads til op mod 80–90 stadeholdere, der sælger alt fra hjemmelavet mad og håndværk til julegaver og dekorationer.

Problemet

#

Bag det hyggelige arrangement gemmer sig en administrativ realitet, som én enkelt person — eventkoordinatoren — skal håndtere fra start til slut:

1. Opsøge potentielle stadeholdere (virksomheder og håndværkere)
2. Sende individuelle ansøgningsformularer pr. e-mail
3. Vurdere ansøgninger ud fra produktkvalitet, originalitet og tidligere deltagelse
4. Udarbejde og sende individuelle kontrakter
5. Modtage signaturer — typisk via scannede PDF’er
6. Udstede fakturaer og følge op på betaling

Alt dette foregår via e-mail, regneark og papir. For 80–90 stadeholdere.

Det er ikke et teknisk problem — det er et administrativt skalereringsproblem. Den menneskelige indsats vokser lineært med antallet af stadeholdere, selvom det grundlæggende arbejde er gentaget 80 gange.

Hvorfor er dette et godt softwareprojekt?

#

Der er tre karakteristika ved Engestofte Gods’ situation, der gør den velegnet til softwareassisteret løsning:

1. Klart defineret livscyklus

#

Hvert stadeholder-engagement følger det samme forløb: kontakt → svar → kontrakt → signatur → faktura → bekræftelse. Det er et flow med definerede tilstande og klare overgange — præcis det, en simpel state machine (eller en statuskolonne i en database) håndterer godt.

2. Repetitiv, teksttung kommunikation

#

De fleste e-mails og kontrakter følger en fast skabelon med variabel indsætning af virksomhedsspecifikke detaljer. Det er netop det, store sprogmodeller (LLM’er) er gode til: generere personaliserede tekster med høj kvalitet på kort tid.

3. Begrænset skaleringsambition

#

Systemet skal håndtere ét event om året med 80–90 deltagere — ikke et globalt SaaS-produkt. Det giver os frihed til at bygge noget specifikt og brugbart frem for noget generisk og over-engineered.

Hvad vi bygger

#

Projektet er en fullstack admin-applikation med et 6-trins flow der modellerer stadeholder-livscyklussen:

OPRETTET → KONTAKTET → KONTRAKT_SENDT → KONTRAKT_UNDERSKREVET → FAKTURA_SENDT → GODKENDT

Systemet er bygget med vores kendte stack:

Den centrale tese

#

Bag projektet ligger en simpel tese: AI egner sig godt til at automatisere repetitive, teksttunge administrative opgaver.

Det er ikke banebrydende AI-forskning. Det er praktisk applikation af eksisterende teknologi på et reelt problem. Og det er præcis den slags projekter, der faktisk leverer værdi.

Eventkoordinatoren bruger i dag mange timer på at skrive de samme typer e-mails og kontrakter igen og igen. Vores system reducerer det til et par klik og et review af AI-genereret tekst — som hun kan redigere, inden hun sender.

Hvad vi ikke vil bygge

#

Det er ligeså vigtigt at definere, hvad vi ikke gør:

• Ingen automatisk beslutningstagning om, hvem der godkendes — det forbliver menneskets vurdering
• Ingen fuldautomatisk e-mail-afsendelse uden review — admin godkender altid, inden der sendes
• Ingen erstatning af koordinatoren — systemet er et værktøj, ikke en autonom agent

Vi bygger et decision support tool, ikke et autonomt system.

Næste skridt

#

Prototypen er bygget og demonstreret. Nu handler det om at gå fra prototype til noget der kan bruges i praksis — med rigtige e-mails, rigtige kontrakter og et interface som Engestofte Gods faktisk gider bruge.

Det er hvad de næste indlæg handler om.