Selling the Same Train as Seats by Day and Berths by Night

If you run rail that changes shape depending on the run, you already know the awkward part isn't the train. It's the booking system. The same carriage that carries a corridor of seated passengers on the morning service folds into a handful of berths for the overnight run, and the platform is supposed to hold both versions of that space without you keeping a second set of books to track which one is live. This article is for operators who run that flip: a service that sells seats by day and berths by night, a route worked as a day train on some departures and a night train on others, or a single consist where some carriages are seated and some are berthed on the same run. If two of those describe your operation, the problem below is one you've already met.

The argument here is narrow on purpose, and it sits next to a different one. A companion piece covers the static inventory model — how berths sit inside compartments inside categories, how a single space sells whole or per-berth, how single-sex allocation works (berth versus seat inventory on sleeper rail goes deep on that). This piece is about the other axis entirely: one physical asset sold as two different shapes depending on what it's rostered to do, and the cost of representing that without running two disconnected systems.

Why this gets expensive quietly

The conversion itself is ordinary railway craft. A second-class couchette compartment is bench seating by day and folds to six bunks by night — the seat back rotates to form the middle berth, and the same physical box sells as a different number of places depending on the hour (Couchette car, Wikipedia). All sleepers and couchettes do some version of this: seats by day, berths by night, and back to seats in the morning (Seat 61, Sleepers and couchettes explained). Operators have done it for a century. The hard part isn't the hardware. It's that the booking platform usually has no way to say "this carriage is worth N seats when it runs as a day service and a smaller count of berths when it runs as an overnight service" — so the operator says it somewhere else.

Somewhere else is a spreadsheet that maps which departures are seated and which are berthed. It's a second product in the booking system pointing at the same physical carriages with no link between the two, so the operator manually keeps their capacities from colliding. It's a clerk who knows, from memory, that Tuesday's service is the seated configuration and Friday's is the berthed one. Every one of those is a place where the two shapes drift apart, and the drift surfaces at the worst moment — a full season, a guest who booked a berth on a run the system still thought was seated, a departure oversold because the seated count and the berth count were never the same number against the same metal.

The Arival 2025 Global Operator Landscape report found roughly two in five operators worldwide still have no online booking system at all, and just under half of those who do are very or extremely satisfied with it (Arival 2025: The State of Booking Tech). The dissatisfied half includes operators forced to run their real capacity logic outside the platform because the platform can't hold it. When the asset has two shapes and the system understands one, the operator becomes the integration layer between them.

One carriage, two inventory shapes

Start with the core case, because everything else is a variation on it. A carriage that runs as a seated day service sells a corridor of seats. The same carriage, rostered to an overnight run, sells far fewer berths — the floor area that held a row of upright passengers now holds a few people lying down. These are not two numbers the operator wants to maintain by hand. They're two profiles of one physical asset, and the platform should hold the asset once and apply the profile that matches the service the carriage is rostered to.

The distinction that matters is between the asset and the service. A booking platform that models capacity as a flat number per departure treats the seated version and the berthed version as unrelated things — two products that happen to share a paint job. The model that actually fits is the one where the carriage is the durable object and each service it runs draws the right capacity profile from it. When the platform schedules each departure as a real service with its own configuration rather than a date on a calendar widget, the same carriage can present as seats on one run and berths on the next without the operator reconciling two inventories by hand. The mechanics of one reservation resolving against the right service — and the same physical unit being held differently depending on what that service is — sit in the durational and multi-sector services capability doc.

The day-train-and-night-train route. Consider a route worked as a daytime seated service on some departures and an overnight berthed service on others, on the same rolling stock. The morning run is a high-count seated service with day fares; the evening run on the identical metal is a low-count berth service with overnight fares. To the operator these are one fleet and one route. To most platforms they're two products with no shared object underneath, so the operator hand-keeps the rolling-stock allocation across both — making sure the carriages rostered to tonight's berth service aren't also showing as seats on a daytime departure that physically can't happen because the train is somewhere else. The platform should know that allocating a carriage to the night service removes it from the seated pool for that window, automatically, not by the operator remembering to block it out twice.

The mixed-mode consist. Now the harder one, and the one most platforms fall over on outright. A single departure runs some carriages seated and some berthed — a few couchette cars for the people who want to sleep, a few seated cars for those who'd rather doze upright and pay less. The total capacity of that one train is the sum of two different unit types: a count of seats and a count of berths, sold side by side, priced differently, on the same run. A platform that holds capacity as one figure per departure can show "places left on the train" but can't tell a guest whether the place left is a seat or a berth — and those are not interchangeable. The booking flow has to present two distinct shapes from one departure, each decrementing its own count, neither borrowing from the other when it sells out.

The reconfiguration day. Rolling stock moves between pools. A carriage in the seated fleet goes into the works and comes back rostered to the berth service; a berth carriage gets pulled for a charter and the seated count on the affected departures drops. Each of those changes what's sellable on every departure the carriage touches, and the change has to ripple to live availability without the operator editing two systems. This is the same shape as a maintenance window taking a unit out of service — the platform removes the right capacity from the right departures, in the right order, rather than leaving a stale number that oversells. When the asset is modelled once and the services draw from it, pulling the asset corrects every affected run at once. When it's two disconnected products, the operator patches both and hopes they match.

The thread through all three is the same: the physical thing is durable, and the shape it sells in is a property of the service it's running. Hold the thing once; let the service decide the shape.

Pricing the two shapes on one booking flow

The capacity problem has a price tag attached, and it's a second place the one-asset-two-shapes structure has to hold. A berth on the overnight run is not priced like a seat on the day run — different fare logic, often a different basis entirely, on the same physical carriage. The platform has to resolve both on one booking flow without the operator keeping two pricing setups in step by hand.

This is well inside what a real pricing engine should do. A seat on a day service can price flat per fare type, while a berth on the overnight version of the same carriage prices per night, or per person, or per compartment — different modes for different shapes of the same asset, resolved on the same booking. A mixed-mode consist prices the seated cars one way and the berth cars another on a single train, and the customer sees one total. Seasonal versioning sits on top of both: the day fare and the berth fare each carry their own peak, shoulder, and off-peak versions that switch automatically by date. The pricing engine capability doc covers how flat, per-night, and per-person modes coexist on one booking — the same engine pricing both faces of the carriage rather than two engines the operator reconciles.

Selling the day seat and the night berth as flexible or fixed. Layer one more real-world wrinkle on top. The same berth often sells as a non-refundable saver to the guest who's certain of their plans and as a fully flexible fare, at a premium, to the one who wants insurance — and the day service does the same with its seats. That's a variation on the underlying unit, not a separate inventory, so the platform holds one physical berth count while presenting two or three fare variations against it, each with its own cancellation terms. When the carriage flips between modes, the variation logic travels with the right shape: the day seat's saver-versus-flexible split and the night berth's are different fare ladders against the same metal, and neither should leak into the other.

Where channels enter, the same discipline applies. If specialist rail-holiday agents take a share of the berth bookings while the daytime seats sell mostly direct and walk-up, the operator wants to cap and reserve capacity per shape independently — hold a slice of berths for direct sales on the overnight run, let the agents have their allocation on the rest, without those rules bleeding onto the seated departures of the same carriages. Capping and reserving by segment, with release timing, is the channel management layer, and it has to key off the shape the carriage is selling in on a given run, not the carriage in the abstract.

What to ask a platform before you trust it with both shapes

Demos run the clean path — one service, one configuration, one sale. The model shows its real shape when you push it on the flip. A few questions separate a platform that holds one asset as two shapes from one that's two unlinked products with a shared name.

Ask the vendor to model one of your carriages on screen, then roster it to a seated day service and an overnight berth service and show you that it's the same object underneath — that allocating it to tonight's berth run takes it out of the seated pool for that window automatically. Ask them to build a mixed-mode departure: some seated cars, some berth cars, one train, and show a guest being offered a seat or a berth from the same run with each decrementing its own count. Ask what happens on a reconfiguration day when a carriage moves from the seated fleet to the berth fleet — does availability correct on every affected departure, or does someone edit two systems? Ask how the seated day fare and the overnight berth fare sit on the same booking flow, each with its own seasonal versions, and how a non-refundable and a flexible variation attach to the berth without touching the seat.

Strong answers are specific and shown live: the vendor drags the carriage between services, the counts move, the price resolves in the right mode for each shape, and the manifest reflects it. Weak answers are the warning signs — "you'd set those up as two separate products", "the team keeps the rolling-stock allocation in a spreadsheet", "the mixed train is just total capacity", or "that's on the roadmap". If the platform can't hold the asset once and let the service decide the shape, the reconciliation between the two shapes becomes your job, every day, for as long as you run it. When you turn this into a full evaluation, the how to choose a sleeper rail booking system guide carries the wider checklist.

Where JetSetGo fits

JetSetGo schedules each departure as a real service with its own configuration rather than a date on a calendar, so the same rolling stock can run as a seated day service on one departure and an overnight berth service on the next, drawing the right capacity profile for the service it's rostered to. A mixed-mode consist sells seated and berth capacity from one departure, each shape allocating against its own count. The pricing engine resolves a flat day-seat fare and a per-night or per-person berth fare on the same booking, with versioned price lists switching by date and fare variations attaching to each shape independently; allocation rules cap and reserve per segment so agent and direct rules apply to the shape selling on a given run. These capabilities are set out in the sleeper rail booking software pillar and the durational and multi-sector services, pricing engine, and channel management capability docs.

Where to go next

If overnight services are your operation, the sleeper rail booking software pillar is the full segment overview. The companion piece on berth versus seat inventory covers the static inventory model — compartments, categories, whole-versus-per-berth — that sits underneath the seated and berth shapes. The mechanics of one asset resolving across multiple services live in the durational and multi-sector services doc, the dual-mode pricing in the pricing engine doc, and the per-shape channel rules in the channel management doc. When you're ready to evaluate platforms against your own fleet, the how to choose a sleeper rail booking system guide turns this into a checklist.

When you want to see one carriage run as seats by day and berths by night on the same platform, book a demo.