Introduction#
In this project, our group will work with a real-world case based on E.G. and their yearly Christmas market. The goal is to investigate how a digital solution can support the planning, administration, and communication around a large event with many standholders, visitors, activities, and practical details.
The project is not only about building an application. It is also about understanding the current workflow, identifying manual processes, and deciding where technology can create actual value. Before choosing technologies or designing features, we need to understand the problem we are trying to solve.
From the information we have gathered so far, the Christmas market involves a lot of coordination. Standholders need to apply, practical information has to be collected, emails are sent back and forth, stand placements must be planned, and visitors need to find their way around the market.
This creates an interesting case because it contains both internal administrative problems and external visitor-facing problems.
The Overall Goal#
The overall goal is to build a digital Christmas market platform that can help E.G. handle parts of the event in a more structured way.
The solution we are considering has three main parts:
- A digital standholder application flow
- Email automation for repeated communication
- A simple live map for visitors
The idea is to reduce manual work while also improving the experience for both the people organizing the event and the people attending it.
Today, a lot of the work seems to depend on emails, manual checking, copy/paste, and personal knowledge. That can work, but it also makes the process vulnerable. If one person holds most of the information, the process becomes harder to scale and harder to hand over to others.
We want to explore how a system can collect information in one place, make it easier to search and filter, and help automate some of the repeated communication.
The Problem We Want to Solve#
The concrete problem we want to solve is that the current process around standholders appears to be very manual.
A standholder may need to contact E.G. by email, receive information, fill out details, send them back, and then wait for further communication. On the internal side, this means that someone has to keep track of applications, missing information, categories, approvals, practical needs, and placement.
This creates several challenges:
- Important information may be spread across emails
- Details may need to be copied manually into lists or documents
- It can be difficult to get a quick overview of all standholders
- Repeated emails take time to write and send
- It can be hard to see which applications are missing information
- Knowledge from previous years may not be easy to reuse
- The process becomes vulnerable if too much depends on one person
At the same time, visitors also need a good overview of the Christmas market. If the event contains many stands across different buildings and outdoor areas, a static list may not be enough. A live map could make it easier for visitors to find specific stands, food, activities, parking, toilets, or other important locations.
The Project Idea#
Our working title is:
Thor og Emils Julemarkeds løsning
The project idea is to build a digital platform that connects the standholder process with a visitor-facing map.
In the first version, a standholder should be able to apply through a digital form. The application should then appear in an admin dashboard, where the event organizer can review it, change its status, and see an overview of all applications.
When a standholder is approved, the information could later be used on a public live map. This means the same data can serve two purposes:
- Internally, it helps with planning and administration.
- Externally, it helps visitors navigate the market.
This is important because it prevents the same information from being written multiple times in different places.
Standholder Application#
The standholder application flow would replace or reduce the need for back-and-forth email communication at the beginning of the process.
Instead of asking for a form through email, a standholder could fill out a form directly.
The form could include information such as:
- Name of standholder or company
- Contact person
- Email and phone number
- Product description
- Category
- Previous participation
- Need for electricity
- Preferred indoor or outdoor placement
- Links to website or social media
- Images of products or stand setup
- Acceptance of practical rules
- Relevant documentation if needed
This would give the organizer more structured data from the beginning. It also makes it easier to validate that required information is included before the application is submitted.
Admin Dashboard#
The admin dashboard would be the internal tool for managing applications.
The organizer should be able to:
- See all submitted applications
- Search and filter applications
- Open details for a single standholder
- Change status, for example new, missing information, approved, or rejected
- Add internal notes
- See categories and practical needs
- Decide which approved standholders should appear publicly
The dashboard is important because it turns many separate emails into one structured overview.
A useful part of the dashboard could be a status-based workflow. For example, if an application is missing information, the system could mark it clearly and generate a suggested email response. If the application is approved, the system could prepare an approval message and make the standholder available for the live map.
Email Automation#
Email automation is one of the most relevant parts of the project because repeated communication seems to be a large part of the current process.
The goal is not necessarily to let the system send every email automatically without human control. A more realistic first version would be to generate email drafts that the organizer can review, edit, and send.
This gives the benefits of automation while still keeping the human in control.
Examples of email automation could be:
- Confirmation when an application is received
- Request for missing information
- Approval email
- Rejection email
- Reminder before the event
- Practical information before setup
- Message when the public standholder list or map is available
For the MVP, we could keep this simple. When the status of an application changes, the system generates a relevant email draft.
For example, if an application is marked as “missing information,” the system could suggest a message asking for the specific missing fields. If the application is approved, the system could generate a short approval email with practical next steps.
This would reduce repeated writing and help make the communication more consistent.
Live Map#
The live map is the visitor-facing part of the solution.
The idea is that approved standholders can be shown on a simple interactive map. Visitors should be able to find stands, categories, activities, and practical locations more easily.
The first version does not need to be a complex GPS-based map. It could be a simple illustrated map or layout with clickable areas.
The map could include:
- Indoor areas
- Outdoor areas
- Standholders
- Food areas
- Activities
- Toilets
- Parking
- Information points
Visitors could search for a product or category, for example “jewelry,” “ceramics,” or “food,” and then see where relevant stands are located.
This part of the project is interesting because it uses data from the admin system. When a standholder is approved and assigned a location, that information can also be used publicly. That creates a connection between planning and visitor experience.
Use of AI#
AI should support the workflow, not replace the organizer.
The most realistic use of AI in this project is as an assistant that helps process text and generate suggestions.
Possible AI features include:
- Summarizing standholder applications
- Suggesting a category based on the product description
- Detecting missing information
- Generating email drafts
- Helping answer simple questions about standholders or categories
For example, if a standholder writes a long product description, AI could create a short internal summary. This would make it faster for the organizer to review many applications.
AI could also suggest a category. If an application describes handmade candles, decorations, and Christmas ornaments, the system might suggest “Christmas decoration” or “crafts.” The organizer should still be able to override the suggestion.
For email automation, AI could generate a draft based on the application status. This would be useful because many emails probably follow the same structure but still need small adjustments.
A possible AI-generated output could include:
- Short summary
- Suggested category
- Missing information
- Suggested email draft
This keeps the AI feature focused and useful.
Technology Considerations#
Since this is a school project, the technology choices need to match both the scope and the time available.
A possible frontend could be built with React. React would make sense because the project needs multiple views, form handling, state changes, filtering, and a dynamic map interface.
The backend could be built with Java and Javalin, since that fits well with the technologies we have already used in our education. The backend would handle applications, statuses, users, categories, and possibly email templates.
For the database, PostgreSQL would be a good choice because the project contains structured data. Standholders, applications, categories, statuses, notes, and map locations can all be represented clearly in relational tables.
A possible tech stack could be:
- React for the frontend
- Java/Javalin for the backend
- PostgreSQL for the database
- REST API between frontend and backend
- OpenAI API or another AI API for summaries and email drafts
- Simple SVG or image-based map for the live map
For the MVP, I would avoid making the map too technically advanced. A static SVG or image with clickable points is probably enough to demonstrate the idea. The goal is not to build Google Maps, but to show how standholder data can become useful for visitors.
Scope#
One of the most important parts of this project is controlling the scope.
The full idea could become very large if we try to include everything:
- Full standholder portal
- Login system
- Admin dashboard
- Email automation
- AI assistant
- Live map
- Visitor chatbot
- File upload
- Payment
- GDPR tools
- Historical data from previous years
- Drag-and-drop stand placement
- Real-time updates
That is too much for a first version.
Instead, the MVP should focus on the smallest flow that demonstrates the value of the system.
MVP#
The MVP could be:
- A standholder fills out a digital application form
- The application is saved in the system
- The organizer can view it in an admin dashboard
- AI generates a short summary and suggested category
- The organizer can change the status of the application
- The system generates an email draft based on the status
- Approved standholders can be shown on a simple live map
This MVP demonstrates the full journey:
Application → administration → AI support → email draft → approval → public map
It is small enough to build, but still complete enough to show the idea.
What We Will Not Build#
To keep the project realistic, there are several things we should not build in the first version.
We will not build:
- A full payment system
- Automatic sending of all emails without approval
- Advanced GDPR administration
- GPS-based navigation
- A full visitor app
- A complete chatbot for all visitor questions
- Drag-and-drop stand planning
- Real integration with E.G.’s live website
- Multi-year historical analysis
- Full document management
These could be future improvements, but they should not be part of the first version.
The main goal is to prove that the workflow can be improved with a more structured digital system.
Questions We Still Need Answered#
Before building too much, we need to clarify some things.
Important questions include:
- How many standholders usually participate?
- How many applications are received?
- What information must a standholder provide?
- Are there existing forms or templates?
- What emails are sent most often?
- Should emails be sent automatically or only generated as drafts?
- What categories are used for standholders?
- Does E.G. already have a map or floor plan?
- Should stands be placed on exact locations or only areas?
- What information should visitors see on the live map?
- Should the public map include activities and practical locations?
- Which part of the process takes the most time today?
The answers to these questions will help us decide what should be included in the MVP and what should be left out.
My Current Thoughts#
I think the strongest version of this project is not just a form or just a map. The interesting part is connecting the internal workflow with the public visitor experience.
If standholder information is collected digitally from the beginning, it can be reused throughout the process. The same data can help with administration, emails, planning, and the public map.
That makes the project more valuable than a single isolated feature.
At the same time, we need to be careful not to build too much. The MVP should focus on a clear and demonstrable flow. If we can show how one standholder moves from application to approval and then appears on a live map, we have already demonstrated the core idea.
AI can then be added as a practical assistant in the places where it makes sense: summaries, categories, missing information, and email drafts.
Conclusion#
This project is about exploring how a digital platform can support a real event workflow. For E.G., the Christmas market involves many practical tasks, many people, and a lot of communication. That makes it a good case for looking at automation, structured data, and AI-assisted administration.
Our goal is to build a solution that reduces manual work, creates a better overview, and makes information easier to reuse. The first version should not try to solve everything. Instead, it should demonstrate a focused workflow from standholder application to admin handling, email support, and a simple visitor-facing live map.
If we manage to keep the scope under control, this could become a strong project because it solves a concrete problem while still giving us room to work with relevant technologies such as React, backend APIs, databases, automation, and AI.