This week, Johan from Engestofte Gods visited our AI Driven Applications elective to talk about running the estate and the work behind its events. His visit was the starting point for the project we’ll take to the elective’s exam: developing software that could make everyday work easier for him and his staff.
To do that, we first needed to understand where their time goes. Johan walked us through customer inquiries, wedding agreements, event planning, accommodation, and the Christmas market. Much of the work involves keeping information up to date across emails, documents, and separate systems. When a customer changes something, someone has to carry that change through to the people preparing the event.
What caught my attention was how much coordination sits behind a single wedding. A couple writes an email. A date gets checked. An offer becomes an agreement, then a set of tasks for the team. Along the way, the guest count might change or breakfast might be added. Johan needs to know what has been agreed, and his staff need a current plan they can work from.
That’s where my project ideas started. Before deciding what to build, I wanted to understand how that information moves through the business and where we could save them some work.
The work behind the venue#
Engestofte Gods is an estate on Lolland offering weddings, parties, conferences, events, and accommodation. Johan works with the bar and events, handling customer contact and planning. An event producer also shows prospective customers around and handles delivery on the day. Brian coordinates the running order, and a regular team of staff delivers the events. There is also a bookkeeper working in e-conomic, a cook, and a gardener.
That division matters. The person who has been talking to a couple for months is not necessarily the person who needs to act on their latest request during the wedding. Information has to survive the handover.
Weddings are their most important source of income, but Johan described a shift in what customers book. Where a hundred guests used to be common, they now see more weddings with fifty or sixty. The business has to make those smaller events work financially. He mentioned a surcharge for sixty guests or fewer and an eighty-five-guest minimum in August, when the dates are particularly valuable.
A late cancellation is another problem: Johan said that with less than three months to go, there is no realistic chance of selling the date again. A date in the calendar represents income they may not be able to recover.
They have also tried to reach the conference market. The barn can accommodate large groups, but the overnight accommodation is arranged around wedding guests rather than business visitors. Johan described one-day events as a better fit. Alongside that are holiday-house and land rentals, and the Christmas market. Each brings its own planning demands.
One point from the interview stayed with me: finding time to step back and develop the business is difficult when you’re already busy running it. Any proposed system would have to earn back some of that time. Giving Johan another place to update would defeat the purpose.
Following a wedding through the business#
The easiest way to understand the problem was to follow Johan’s description of a wedding from the first inquiry.
A couple finds Engestofte online and calls or writes. Johan checks whether their preferred date is available, sends a standard reply based on a template, and starts a conversation about visiting the venue. Either he or the event producer shows them around. A meeting confirmation also becomes part of the communication thread.
If the couple wants to continue, Johan prepares an offer with the optional extras. He collects their name, address, and phone number, creates the customer in e-conomic, and manually fills in an agreement confirmation. That document sets out exactly what the parties have agreed. It is sent through e-conomic using a template and returned by the couple.
The conversation can continue while the agreement is being settled. Johan gave breakfast as an example: if the couple decides to include it, an addition has to be made to the agreement. A DKK 25,000 deposit invoice is then sent and paid. Only at that point is the agreement in place and ready to become operational work.
Trello is where the event becomes something the team can deliver. They use yearly wedding boards and templates, with information and tasks covering the room, table setup, decorations, accommodation, drinks, food, invoices, and staff. Labels indicate responsibility, and a colour status shows when things are ready. Once everything is green, the delivery team takes over.
Brian then contacts the toastmaster about speeches and other contributions, puts them into a schedule, and prints it for the staff briefing. The process ends with people using that information to run a real evening. An omission upstream can reach the kitchen or the floor long after the customer thought it had been settled.
An inquiry also needs to remain distinct from a confirmed event. Someone asking about a date has not booked it. Someone viewing the venue has not accepted an offer. If I collapse those stages into one booking screen, I lose exactly the information Johan needs to manage the conversation.
Where the information starts to drift#
The recurring problem in my notes is manual transfer. Email holds the conversation. e-conomic holds customer and financial information. Trello holds the work needed to prepare and run the event. Johan carries a lot of the context between them.
Each tool has a purpose. Trouble starts when the same fact has to be maintained in several places.
Take a hypothetical change from eighty-five guests to seventy-eight. It sounds like one update. But it could affect the offer, the food order, the table setup, and the information used to brief staff. Saving it in one place doesn’t mean all the other places now agree.
Accommodation adds another dependency. Johan explained that holiday houses are managed separately, but a wedding can reserve them. That requires updates in both the rental process and the event planning. Cleaning staff then need check-in and check-out dates, whether cleaning is required, and the relevant linen information.
The interview also exposed a gap earlier in the process: there is no CRM for keeping track of inquiries. A customer might agree to get back in touch months later, but there isn’t a system holding that next step. Johan wanted something more proactive, reminding him who needed to be contacted.
Finding the relevant email correspondence was another difficulty. An event can have a long history, and the useful answer may be buried in a thread rather than visible beside the current plan.
Johan was explicit about the priority. In translation, my notes record it as:
Eliminate human errors when creating things manually from emails and other systems, and make sure everything stays up to date.
His requests followed from that: a CRM for inquiries, reminders to contact customers, and integration with e-conomic so the same information only needs maintaining once. He also wanted website forms and better support for Danish, English, and German. The common thread was less time moving information around and fewer opportunities to miss something.
The Christmas market has the same problem at scale#
Johan described a Christmas market that had grown from around 1,200 to 6,000 visitors, with 110 stalls. It is important to the year’s business, and the administration starts almost as soon as the previous market ends.
Stallholders receive a thank-you message and an application for the following year. The team assesses who should return and where to place them, including avoiding awkward groupings of stalls selling the same things. Around the summer holidays, a blank PDF goes out again. Responses are slow, and staff sometimes have to fill it in for applicants. September brings reminders and a rush of applications; once a stall is allocated, it is created manually in e-conomic, with payments collected around October.
Johan put the correspondence at roughly a thousand emails over the process. Many stallholders are not particularly comfortable with computers, so a new form alone would not solve it. He wanted automatic reminders and a map of the stall positions. The event itself is again coordinated through Trello.
That helped put the wedding discussion in context. Across different parts of the business, staff are chasing replies, copying details, and checking that agreements match the plan. The market was a clear project opportunity. I was more interested in the inquiry and planning process for weddings and other events.
The idea that started to take shape#
I began thinking about a shared place for an inquiry to develop into an event, keeping the history with it.
The inquiry could hold the customer, preferred date, guest count, accommodation needs, and next action. Once the booking is confirmed, that information could carry into an event page with the current plan, documents, and outstanding decisions. A promise to call after New Year would have somewhere to live.
Different people would need different parts of it. Johan needs the customer conversation and missing decisions. The kitchen needs numbers, menu details, and timings. Service staff need the setup and running order. Cleaning staff need the accommodation schedule. A useful overview depends on who’s opening it.
The central event page is my proposed response to the information problem Johan described. It still needs checking against how the team works.
I would also be careful with Trello. Johan said the owner is happy with it, and the team already uses it to organise delivery. There may be value in connecting event information to that workflow. Before deciding how, I’d want to see an anonymised example of a real event and understand what the template already does well.
A table plan with a clear handover#
The more specific idea I wanted to explore was a table-layout tool connected to the event.
A customer could open a link, see the room, and propose a setup: choose tables, move and rotate them, and assign guests. Johan could then review the proposal before it became the plan staff should use.
The couple and Engestofte would see the same proposal, with a clear distinction between a draft and an approved layout. Staff would know which version to use.
Some checks could happen before Johan reviews it. Tables should fit inside the room, avoid overlapping, and leave agreed areas clear. Available seats should match the intended guest count. Those checks would need real room measurements and rules from Engestofte; I can’t derive them from the interview alone.
After approval, staff would need a usable setup plan, potentially as a printable document alongside Brian’s running order.
The table planner emerged from my thinking about the setup tasks. I’d want to show Johan the idea and check whether it solves a recurring problem before treating it as a requirement.
Where AI might help#
The useful AI opportunities I could see were mostly around written information.
For example, an inquiry might say that a couple wants a wedding next summer, expects around eighty-five guests, and would like accommodation. A model could suggest those details as fields and flag that the exact date is missing. Johan would still need to check the interpretation. “We’d like rooms” isn’t a confirmed accommodation booking.
A summary of a long email thread could also help, provided the original messages remain available. Suggested replies or a short overview of unresolved questions might save time without giving the model responsibility for making commitments to the customer.
Other parts call for ordinary programming. A reminder on an agreed date, an overlapping table, or a room already reserved can be checked against explicit rules and stored information. I would start there. There’s enough uncertainty in understanding the workflow without adding uncertainty to a check that should be precise.
Coding agents could help develop the planning tool. Any AI inside it should have a specific job, with suggestions staff can review.
What I still need to ask#
The interview was enough to find a direction, but several decisions remain open. I’d want Johan to show me a real inquiry and walk through what happens to it next. Which details are needed before it becomes a confirmed event? Where is the current guest count recorded? What happens when something changes after the team has been briefed?
For the table planner, I’d need to know how layouts are agreed today, which rules matter in each room, and what staff need on the final plan. I’d also want to know whether customer access would make the work easier or create another task for Johan to manage.
The broad idea list could easily grow into a whole business system: inquiries, calendars, accommodation, resources, tasks, documents, and accounting integration. For a student project, I’d rather choose a small part of that process and follow it all the way through. A customer proposal that reaches Johan and then becomes a usable staff plan is a promising candidate.
For now, the outcome is an idea to investigate: event information that stays connected as it moves from customer conversation to planning and delivery, with a table-layout and approval flow as a possible focus. The next post is where I’ll narrow that down and get into what I’m building.
This is part six of my posts on this semester’s AI-driven applications elective. The account of Engestofte’s workflow is based on my notes from Johan’s presentation and interview; the proposed features are my ideas arising from it.