Walter's Hospitality

An events company ran on spreadsheets, email and paper. Over twelve months we replaced that with one system for the planners, the office, and every outside vendor they work with.

Role
Product Designer
Team
12, at Arbisoft
Duration
12 months, 2023
Status
Shipped

01/The problem

Every event lived in five places.

Walter's plans weddings, corporate events and private parties. Each one involves florists, caterers, photographers and a dozen other vendors. Before this project, the plan for an event was spread across a spreadsheet, an email thread, a paper file, and two people's heads. Teams could not see each other's updates, and a lot of work was retyping.

The worst of it was vendor management. Every vendor was handled a different way, so the same event could go smoothly with one florist and badly with another. Clients felt that difference.

02/The finding

Vendors are not one kind of user.

I interviewed the planners, the office staff, and the vendors themselves, one at a time. I also sat through their four-meeting planning cycle to see where the information actually changed hands.

The finding that shaped the whole product: one vendor form would not work. A florist selling fixed packages needs a price list and a calendar. A florist doing custom work needs inventory, quantities and approvals. A photographer needs neither, and needs a shot list instead. Forcing them into one form is what the spreadsheets had been doing, badly.

Interview notes sorted by role and by where the hand-offs broke.

03/The decision

A profile that changes shape by vendor type.

Instead of one vendor record, each vendor type gets its own set of fields, services and ways of being contacted. The planner sees the same layout for every vendor. The vendor sees only what applies to them. That kept the system learnable for the office without making a caterer fill in a florist's form.

Every role got its own portal: admin, staff, and each vendor. I prototyped each one and put it in front of the person who would use it, in their own portal, before it was built.

The vendor profile. Same frame, different fields.
Vendor-side screens.

04/The build

Reports the office had never had.

With events and vendors in one system, the numbers came for free. I worked with the finance side to list what they had been assembling by hand each month, and built a reports page around it: revenue by period, and which packages sell.

Twelve months is a long project. The way to keep twelve people aligned was to design one role's flow end to end, ship it, and move to the next, rather than design everything and hand it over at once.

Revenue and packages, without the spreadsheet.

05/Outcome

The spreadsheets went away.

The platform shipped and replaced the spreadsheet, email and paper process for planners, staff and vendors. The immediate gain was time: the retyping stopped, and updates were visible to everyone at once.

I do not have usage numbers from after launch. The client did not instrument the system, and I moved on before that changed. So this study describes what was built and why, and makes no claim about hours saved.

What I took from it: in enterprise work, the design problem is mostly a disagreement problem. Twelve people and a dozen vendor types wanted different things. The job was getting them to agree on one shape, then drawing it.