Velvet Stay

Overview

What this is.

Velvet Stay is a booking and guest portal study: rooms as inventory, rates as rules, guests as people with stays. The brand is quiet luxury; the system underneath is dates, holds, and payments.

The challenge

What was actually hard.

Hospitality sites sell a mood and then trap the guest in a datepicker from 2014. Ops still runs on a printout. We wanted one inventory, two surfaces.

Objectives

What we optimized for.

1. 01

   A booking flow that states total cost early

2. 02

   Holds that expire

3. 03

   A guest portal for the stay that already exists

4. 04

   Staff console for exceptions (late checkout, room move)

Strategy

The bet.

Inventory is a calendar of inventory units, not a marketing grid. Brand photography is large; the form is small and sequential. No upsell modal before the guest has a date.

Discovery

What we had to learn first.

We watched a front-desk workaround: a sticky note on sold-out weekends. That became a constraint in the rate engine.

UX

How it behaves.

Search → stay summary → guest details → pay. The summary is sticky. Portal: upcoming stay, house info, a request that becomes a ticket.

Design

How it looks when it is working.

Warm off-white, wine, and charcoal. Photography bleeds. UI is hairline and serif for headlines only. Buttons stay sharp.

Engineering

How it is built.

Availability queries that cannot overbook under concurrency. Stripe for capture. IBE-like API for the site and a modest staff UI.

Architecture

Boxes we can defend.

Technology

The stack for this study.

Implementation

The work, in order.

1. 01Inventory calendar
2. 02Rate rules
3. 03Booking API with holds
4. 04Guest portal
5. 05Staff exceptions
6. 06Email templates that match the site

Result

Outcomes — illustrative until measured.

Replace with measured results after a client engagement.

Voice

A quote worth keeping — later.

“Replace with a GM: guests stop calling to ask what they already paid for.”