Interior crew rotate, and the preference sheet in the folder does not. By the second season it is a snapshot of whoever last printed it, and the knowledge that actually runs the interior is still in people's heads.
What the sheet is supposed to hold
A working preference record is not a personality profile. It is a set of facts the next watch can execute without a briefing from the person who has just signed off.
Dietary: allergies, intolerances, religious constraints, what is actually eaten at breakfast, what must never appear on a platter. Not "healthy" or "likes fish". The difference between a nut allergy and a preference against coriander is the difference between a medical incident and a slightly worse lunch.
Cabin: which cabin, which side of the bed, temperature, lighting, blackout, pillows, whether the television is on or off, whether the minibar is stocked or empty. Stewards learn this in a night. They also leave in eight weeks.
Wine and bar: house pours, vintages that must not be touched, what was drunk last visit, what was sent back. Cellar space is finite. A preference that is not in the record becomes a guess on the provision list.
Activities: tenders, toys, dive, beach setup, restaurants that worked, times the guest is not to be disturbed. The deck team needs the same facts as interior. Failures are the first thing a handover drops, because they are not on the template.
What a handover actually loses
A good interior handover is a day of walking the yacht, opening cupboards, and talking. A bad one is a PDF, a WhatsApp voice note and a taxi to the airport. Most sit between the two. Even the good ones lose structure.
The outgoing chief stewardess knows that the owner's partner changed from still to sparkling in May, that cabin 4 runs cold on the starboard fan coil, and that the Bordeaux on the sheet was finished two charters ago. None of that is exotic. All of it is operational. If it is not in a record the incoming crew can search, it is a story, and stories do not survive a second rotation.
Paper sheets go stale in a specific way. They are updated when someone remembers to reprint. A change made during a trip, a new allergy, a wine rejected, a cabin swap, lives in the trip notes or in a message to the chef. The sheet in the folder is last season's version. Incoming crew, being conscientious, follow the sheet. That is how a yacht serves a dish the guest has not eaten for a year.
A spreadsheet on a laptop that belongs to one person is the same failure with better fonts. If the chef, the steward on service and the purser ordering stores are not reading the same row, you do not have a preference system. You have three.
Interior rotations are often shorter than officer rotations. Handover days are also work days. Rest hours still apply. The pressure to stay for an extra few hours and brief the incoming stewardess is how rest records and actual fatigue drift apart. A record the incoming crew can read without a two-hour debrief is how you avoid buying continuity with unpaid overlap.
Why charter yachts feel it first
A private yacht with a stable owner and a long-standing chief stewardess can paper over a weak record for years. The same person is there. The failures are small and forgiven.
Charter is a different machine. Guests change every week or two. Brokers send a preference sheet that may be years old, filled in by a PA, and silent on what happened last time aboard this yacht. The on-board interior team has days, not a season, to look competent. Returning charter guests, the ones a programme wants, expect the vessel to remember them. The broker's file and the yacht's file are rarely the same document.
Crew turnover is higher on many charter interiors. A stewardess may do one season and move. The chef may be freelance around owner trips. Each of those people holds a slice of guest knowledge. When they leave, the slice leaves, unless the yacht itself kept it.
The seam with the booking platform makes this worse. Availability, APA and guest paperwork often live in a broker or agency tool. That tool is not the service record. Dietary notes in a booking form do not become a provision list. Someone has to re-type the operational facts, and in a turnaround week that someone is busy stripping cabins.
The vessel should keep the record
The test is simple. Imagine the entire interior signing off tonight, with a written handover but no conversation. Could the incoming team serve breakfast tomorrow without guessing?
If the answer depends on one person's memory, the record belongs to that person, not to the yacht. Preference knowledge should survive the crew the same way a work-order history should survive a chief engineer.
Dietary notes belong where provisioning and the galley can read them. Cabin setup belongs on the cabin, so a joining stew can set the room before the guest walks in. Wine belongs on the guest and in the cellar list. Activities belong on the programme so deck is not hearing about a 0900 launch at 0830.
Guests do not need to see the engine room. They do need a way to ask for the cabin to be colder, to look at tomorrow's plan, and to request dinner without finding a stew. That guest-facing layer is only useful if what they ask becomes part of the same record the crew work from.
YachtOS Guest is that layer: itinerary, dining, cabin requests and a concierge the guest can speak to from a device on board. The point is not a gadget in the suite. The point is that a preference logged once is the same fact the provision list, the cabin setup and the next charter brief all read.
Crew still decide what is possible. A dusk jet-ski request still needs a driver, a tender, and a captain who is happy with the light. The system does not overrule that. It stops the request from existing only in a corridor conversation.
What this means on board
Stop treating the preference sheet as a document you reprint. Treat it as a live record owned by the yacht. Update it when the fact changes, not at the end of the season. Put failures in it, not only likes. Make sure chef, interior and purser read the same source. On charter, do not trust the broker file as the service file.
The Guest app is live if you want to see the guest side of that idea. Humans stay in command of service; the system does not greet the guest for you. Try the live apps, or request a demo with a real preference sheet and a real rotation in mind.