# Front Office Standard Operating Procedure: [Property name]

> The standard operating procedure (SOP) for a hotel front office:
> check-in, room keys, payments and deposits, guest data and privacy,
> check-out, night audit and incident handling. Payment steps are
> written to keep card data out of the front office as far as possible,
> in line with PCI DSS v4.0.1 (PCI Security Standards Council, June
> 2024). Based on common hotel front office practice. Replace every
> `[bracketed]` value and every row marked *Example*. This is a
> documentation format, not legal advice: check the current official
> rules where you operate and a qualified professional.

<!--
Guidance: How to use this template
- Write the steps your desk actually follows, in the order a new
  agent would do them. Each step says who, what system and what to
  record.
- Local law decides guest registration (some countries require
  identity details of foreign guests), tourist taxes, data retention
  and age limits. Fill section 2 from your own legal check.
- Common pitfall: staff copy card numbers onto paper or email to
  "help" a guest. Section 4 removes that need and section 7 makes it a
  reportable incident.
- Related templates: generic SOP format (`ops/sop`), shift handover
  (`ops/shift-handoff`), PCI DSS scoping (`compliance/pci-dss-scoping-segmentation`),
  guest incident report (`hospitality/guest-incident-report`).
-->

## Document control

<!-- Guidance: Review after any change of property management system (PMS), payment terminal, or law, and at least once a year. -->

| Field | Value |
|---|---|
| Document ID | [HOS-FO-SOP-001] |
| Version | [1.0] |
| Property | [*Example:* Corvelle Quay Hotel (fictional), 180 rooms] |
| Systems | [PMS name, payment terminals, key encoder] |
| Owner | [@front-office-manager] |
| Approved by | [@general-manager] |
| Effective from | YYYY-MM-DD |
| Next review | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | 2026-10-30 | Front office manager | First issue |

## 1. Scope and roles

<!-- Guidance: Say who may do what. Rate overrides, refunds and key re-issues to an unverified caller are the usual gaps. -->

| Role | May | May not |
|---|---|---|
| Front desk agent | Check in and out, take payment on terminal, issue keys to verified guests | Override rates beyond [10]%, refund above [100.00], disclose room numbers |
| Supervisor | Approve overrides and refunds up to [500.00], re-issue keys after ID check | Change night audit figures |
| Duty manager | Approve exceptions, handle incidents and complaints | Waive policy without recording why |
| Night auditor | Run night audit, post room and tax charges | Edit closed folios without approval |

## 2. Check-in

<!-- Guidance: Keep identity checks proportionate: look at the ID, record only what the law or your policy requires. -->

```mermaid
flowchart TD
  A["Guest arrives"] --> B{"Reservation found?"}
  B -- "No" --> C["Offer walk-in rate, check availability"]
  B -- "Yes" --> D["Verify identity against booking"]
  C --> D
  D --> E["Record registration data required by local law"]
  E --> F["Payment guarantee on terminal: pre-authorisation or token"]
  F --> G["Assign room, encode keys"]
  G --> H["Explain breakfast, Wi-Fi, check-out time, quietly show room number"]
```

1. Greet the guest and find the reservation by name and arrival date.
2. Look at a photo ID and confirm the name matches the booking. For
   bookings made by a third party, follow the third-party authorisation
   on the reservation.
3. Complete registration fields required by local law [list them].
   Do not scan or copy IDs unless the law requires it; if it does,
   store the copy in the PMS, not on desktops or email.
4. Take the payment guarantee on the terminal (section 4).
5. Assign the room, encode [2] keys and write the room number on the
   key wallet. Never say the room number aloud where others can hear.
6. Note special requests, accessibility needs and allergies (passed to
   food and beverage with the guest's agreement).

## 3. Room keys

<!-- Guidance: Most room-entry incidents start with a key issued to the wrong person. -->

- Re-issue a key only after the guest shows ID or answers [two]
  verification questions recorded at check-in, and only for a guest
  registered to that room.
- Calls asking for a room number or for a guest's presence: do not
  confirm. Offer to connect the call or take a message.
- Lost key reports: cancel the old key in the encoder and record it.

## 4. Payments and deposits

<!-- Guidance: The aim is that no full card number or security code ever reaches the front office in readable form. PCI DSS v4.0.1 requirement 3.3.1 forbids storing sensitive authentication data, including the card verification code, after authorisation. Check your scope with your acquirer. -->

1. Card present: the guest inserts or taps the card on the terminal.
   Staff do not handle or key in card numbers.
2. Card not present (phone, email): send the guest a secure payment
   link from the payment provider. Do not accept card numbers by email,
   chat or note; if a guest sends one, do not reply with it, delete it
   as section 7 describes and ask the guest to use the link.
3. Pre-authorisation: [*Example:* room and tax for the stay plus 50.00
   per night for incidentals]. Tell the guest the amount held and when
   it is released.
4. Displays and printouts show the card number masked (*Example:* last
   four digits only).
5. Cash: count in front of the guest, issue a receipt, keep the float
   at [amount], drop excess in the safe with a second signature.
6. Refunds go back to the original payment method.

## 5. Guest data and privacy

<!-- Guidance: Use your privacy notice and records of processing. Examples of laws: EU GDPR and UK GDPR (lawful basis, rights, retention), California CCPA as amended by CPRA. Check what applies. -->

- Collect only the data needed for the stay, the law and the guest's
  requests.
- Guest requests to see, correct or delete their data go to [@privacy
  contact] within [1] working day; do not handle them at the desk.
- Registration records are kept for [period required by law] and then
  deleted by [process].
- Lists of guests are never given to callers, visitors or other guests.
  Police requests go to the duty manager, who records the legal basis
  and what was disclosed.

## 6. Check-out and night audit

<!-- Guidance: Check-out ends with a correct folio and a released pre-authorisation. Night audit makes the PMS day match the money. -->

Check-out:

1. Confirm minibar, restaurant and other charges; ask about the stay.
2. Print or email the folio (email only to the address on the
   reservation).
3. Settle on the terminal, release unused pre-authorisation, collect
   keys.
4. Late check-out: approve per policy and record the fee.

Night audit:

1. Post room and tax charges for every in-house room.
2. Check no-shows against the guarantee policy and post charges.
3. Balance payments in the PMS against terminal and cash totals; record
   and report any difference over [5.00].
4. Run the end-of-day report and back-up as the PMS requires.

## 7. Incidents and escalation

<!-- Guidance: Name the trigger and the first call. Staff should never have to decide alone whether to call emergency services. -->

| Situation | First action | Record |
|---|---|---|
| Medical emergency | Call emergency services [number], then duty manager | `hospitality/guest-incident-report` |
| Theft or lost property claim | Duty manager, security; police if the guest asks | Guest incident report |
| Card data received in readable form | Do not copy it; delete it as IT instructs; tell the duty manager | Security incident log |
| Unwelcome visitor asking for a guest | Do not confirm; call security | Shift log |
| Complaint that staff cannot resolve | Duty manager within [15] minutes | Complaint log |

## 8. Training and checks

<!-- Guidance: Train at induction, check monthly. Mystery calls asking for a room number are a useful test. -->

| Check | Frequency | Owner |
|---|---|---|
| New agent trained on this SOP and signed | Induction | Front office manager |
| Key re-issue test call | Monthly | Supervisor |
| Desk check: no card data on paper, screens locked | Weekly | Duty manager |
| Payment terminal inspected for tampering | [Daily] | Opening agent |

## Standard and licence note

Based on common hotel front office practice. Payment steps follow the
data protection aims of PCI DSS v4.0.1 (PCI Security Standards Council,
June 2024), cited by name and requirement number only (official text:
PCI Security Standards Council, free with licence agreement:
https://www.pcisecuritystandards.org/document_library/). Privacy laws
are named as examples only. All text and the fictional property are
original. Check the current official versions before use. Template
licence: MIT.