Illustrative animation — not product footage.
The problem
Event operations lived in chats and spreadsheets
An event-planning business runs on details: who the client is, what was agreed, what changed since, which vendor is confirmed, who owns which task, and what happens on which day. Before the portal, those details lived across chat threads, spreadsheets, inboxes and memory — each one correct in isolation, none of them the whole picture.
The operational cost of that setup is constant re-checking: the state of an event had to be reconstructed from scattered sources every time someone needed it, and a change agreed in one channel didn't automatically reach the people executing in another.
How it works
One workspace, one current view of every event
The portal is a private web workspace for the team. Everything hangs off two spines — clients and events — so any piece of work is always in context:
- Events and calendars. Each event has its own page: dates, schedule, the people involved and everything attached to it. Calendars show what is coming across all events.
- Tasks with owners. Work items belong to a named person, so "who is doing this" is a fact in the system, not a question in a chat.
- Change requests. When a client changes something, the change is captured as a request and tracked — agreed changes stop evaporating between conversations.
- Vendor coordination. The vendors involved in an event are managed alongside it, keeping outside parties tied to the event they serve.
- Messages, notifications and email. Internal conversations happen inside the portal, next to the work they are about; notifications and email keep the team up to date without leaving the system.
- AI assistant. An assistant inside the workspace helps the team work with all of the above.
The result is a single, current operational view: open the event, and what you see is the state of the event.
Capabilities
What the portal centralizes
Privacy by designThe portal is private and stays private: no client names, event details, vendors or internal data appear here, and the portal itself is not publicly accessible. This page describes the system, not its contents.
The outcome
From reconstructing state to reading it
The company now operates from one system instead of many: the current state of any event is something the team reads, not something it reassembles from chats and spreadsheets. New information — a task done, a change requested, a vendor confirmed, a message sent — lands in the same place the rest of the operation already lives.
For a prospective client, this project shows the other half of my work: not a product I sell, but a custom internal tool shaped around how one specific team actually operates — designed, built and delivered end to end.