A guest portal the front desk can run

The staff side decides whether a portal stays accurate: stay links from reservations, requests with an owner and publishing with a readiness checklist.

4 min read

Plain white key card resting on a folded wool throw at the foot of a neatly made hotel bed.

A guest portal is only as good as the staff side behind it. If creating a link, answering a request or changing a notice needs outside help, we think the portal drifts out of date and guests stop relying on it. Guester’s portal is designed for the front desk to run: staff create stay links, route requests to a team and publish with a readiness checklist in view.

Staff create a personal link for each stay, from a PMS reservation or through a manual form. Every link comes with a QR code to print, for example on a card handed over at check-in. The code turns a long address into something a guest can open with a phone camera in a moment.

A link tied to a reservation is a link the hotel can account for. Staff know which stay it belongs to, so changing or withdrawing it is a deliberate act rather than guesswork. That matters more than it sounds once a property has many stays running at the same time.

Links are not fixed once issued. Staff can edit a link, rotate it or revoke it. For example, staff can rotate a link that was shared further than intended or revoke one for a stay that ends early. Link grace hours are a hotel setting, alongside the default request target and the time zone.

Underneath, the staff side is strict about context. The hotel always comes from the signed-in session rather than from anything a page remembers. Nothing is stored in the browser.

Requests that reach the right team

A guest request is a small promise. Small promises are the easiest ones to drop, because nobody owns them until something goes wrong. The portal gives each request a home: a default request target set by the hotel, then assignment to whoever should handle it.

From there, staff work the request like any other job. They filter the list, change the status as things move and keep internal notes beside it. For example, a request for extra pillows can go to housekeeping, carry a note from the front desk and close with a status change instead of a phone call.

Internal notes do quiet work. They carry context from one shift to the next without putting it in front of the guest. A request picked up at the start of an evening shift should not have to be explained again by whoever took it in the morning.

The overview shows open requests next to recent activity, so a manager can see what is waiting without opening each one. That overview is the first place to look when a guest mentions a request that never seemed to arrive. The portal is part of Guester, which brings guest information and team operations into a shared workspace for independent hotels.

Notices inside the portal

Some things a hotel needs to tell its guests are not answers to requests. For example, the pool may close early one evening, or breakfast may move to another room for a few days. The portal handles these as in-portal notices with timing rules, so each notice can be set to show when it is relevant.

Timing rules also change who has to remember what. A notice can be prepared in advance instead of being posted by hand at the right moment. The front desk sets it up once and gets on with the shift.

Notices do not go out by email, SMS or messaging apps. They live inside the portal, where a guest goes to look for information about the stay. We think that boundary is right: a portal is a place the guest chooses to visit, not another channel that interrupts them.

Publishing with a checklist

In our view, publishing is where a portal most easily goes wrong. Half-finished pages can go live, old information can linger and nobody is quite sure which version guests are seeing. The staff side answers that with these pieces:

  • An overview with publish status and a readiness checklist.
  • Portal Studio, a full-screen editor with publishing, versions and a media library.
  • A preview of the published version.

The readiness checklist does the most work. It turns the question of whether the portal is ready into visible conditions rather than a feeling. Versions give the team a record of what was published. The preview removes guesswork about what guests are actually seeing.

Together, these pieces turn upkeep into a routine rather than a project. Portal Studio also guards against a quieter failure: two people saving over each other’s edits, which never overwrite someone’s work silently covers in detail. Portal analytics come with CSV export, so the hotel can take the figures into whatever it already uses for reporting.

The test of a guest portal is whether it is still accurate long after launch. That depends less on the pages guests see than on whether the people at the desk can keep them current between check-ins. A portal the front desk can run is a portal that stays true to the hotel.

More in Hospitality