Feature Guide · Permits
Eligibility is not a sticker.
It is a checked relationship.
A permit is a standing claim on one plate. The product calls that issued record a vehicle pass in code, but it is not a second entitlement layered onto the permit. The separate thing is the stay or package that defines whether the permit may be issued and who pays.
Three verbs
Attach a visit. Claim a permit. Auto-issue only when the payer allows it.
A valet or partner can attach a live visit to the correct stay. The holder claims a covered or paid permit. Automatic issuance belongs only to a folio arrangement where the property, rather than the holder, is responsible for payment. Covered eligibility is not the same thing as a person's consent to enroll.
What it is
Stay or package
The source terms- Defines who is eligible and where
- Defines whether permits are enabled
- Defines holder, partner, or folio payment
Permit / vehicle pass
The issued plate claim- Claims one specific plate
- Lets plate-first check-in resolve coverage
- Carries its own active lifecycle
Who uses it
A partner or operator defines the stay arrangement. The eligible holder claims or purchases their own permit unless the property's folio relationship is allowed to issue it automatically. The valet attaches a visit to the appropriate stay and works the vehicle; the valet does not invent the permit.
The setup order
First define who pays, who is eligible, where the arrangement applies, whether permits are enabled, and whether the property funds any permits. Funding changes who pays, not how many permits may exist. Next establish the person's stay. Then let the authorized issuance path create the permit for a plate. Only after that should the plate be expected to resolve as covered at the curb.
→The flow reflects current product ownership without exposing internal collection names or claim-record mechanics.
The daily loop
At check-in, an active permit for that plate and location is the strongest coverage signal. If none exists, the valet can attach the visit to a chosen stay; the appropriate holder or folio flow decides whether coverage may be issued. If no stay is chosen, the car remains a guest visit rather than being silently guessed into an arrangement.
The edge cases
The system refuses overlapping active coverage for one plate at a place. A disabled-permit arrangement cannot mint one anyway. Changing a car depends on who owns the permit: a holder-authored permit is not something a valet can casually move to another vehicle, while a property-funded folio record has a correction path for operational mistakes.
Linking a visit to a stay is deliberately permissive because it records context. Issuing coverage is deliberately stricter because it creates a right with financial and operational consequences.
What it deliberately does not do
It does not let a valet manufacture eligibility, interpret an attached stay as payment, or auto-enroll a holder merely because their parking would be covered. It also does not guess the stay from a name or room alone. A missing relationship stays visible until a person resolves it.
What it connects to
A permit - the VehiclePass record in the product model - connects stay or package terms, payer, holder, location, plate, recurring or one-time payment, and live valet sessions. That chain is why the product can answer a simple curb question - “Is this car covered here now?” - without relying on a hangtag or a staff member's memory.
Next guide
Put the operator's front door online.
The Operator Website and Leads guide covers the editable public site, proposal form, and the lead record that arrives in the console.
Concrete next step: write one stay configuration in plain language and verify that every payer, holder, location, and plate rule is unambiguous.
