Operator help center

Open Locations, create the location, and enter its public name, address, timezone, and operating details. Add zones or spaces when the location needs capacity tracking or separately managed areas.

Choose a memorable shortcode and generate QR codes from the QR codes area. A QR code is simply a link, so anyone who has the link can open it. Unlisted locations are omitted from ParkTab location search and shortcode discovery; unlisting cannot prevent a previously shared direct or QR link from being used.

Assign the intended pricing group, confirm that at least one active base rate applies, and use the pricing tester for representative arrival times and stay lengths. Also check taxes, service fees, maximum stay, and payment options.

Publish only after the driver flow is complete. Test the public link in a signed-out browser and scan the real printed QR code before installing signage.

A pricing group owns rate plans, and locations receive pricing by being assigned to groups. Each plan is a versioned pricing document. Base plans are matched automatically; access plans are reached through a pinned link or other controlled entry path. Lower priority numbers are considered first.

Use bucket pricing when the sign gives one total price for each stay-length band. Use progressive pricing when charges accumulate over time. Use a package when one price includes parking until a stated exit deadline. Add schedule windows, stay limits, day boundaries, overage behavior, caps, taxes, and modifiers only when the posted rules require them.

Saving a pricing change creates a new immutable version. Keep useful gaps between priorities, such as 10, 20, and 100. Create plans in Pricing → Plan library. Unassigned plans stay in the library. The separate Available for overrides card controls which groups’ workers may select a plan temporarily. Assigning a plan automatically grants availability to that group; unassigning preserves availability. Remove availability explicitly to prevent new selections, after unassigning the group. New unassigned plans need an availability group before workers can choose them. Use the Assignments card in the plan editor to add or remove pricing groups; changes take effect with Save plan. A plan can be assigned to zero or more groups. Removing its last group does not end temporary overrides, and existing sessions keep their agreed pricing. Locations inherit plans from their groups, and schedules still decide when an assigned plan is eligible. Leave a plan unassigned until it is ready for normal pricing.

Use the pricing tester with times just before and after schedule boundaries, the minimum and maximum stay, overnight stays, grace periods, vehicle or service modifiers, taxes, and overage. Compare the rendered summary and total with the physical sign before activation.

In the rate-plan editor's Schedule & eligibility section, set Must leave by to a local 24-hour time, such as 05:00. This optional per-plan setting applies to bucket, progressive, and package pricing, even when overage is allowed. It resolves to the next occurrence after entry in the location's timezone. Leave it blank when the plan has no hard departure deadline. It is separate from a package's pricing exit deadline.

For a school lot open to self-parking from 5pm until 5am, set the entry window to 17:00–05:00 and Must leave by to 05:00 on each applicable plan. Entry windows decide whether a stay can start; they do not by themselves end an existing stay. With no eligible plan, self-park quoting is unavailable. Check other base plans, private/access plans, and event overrides so they express the intended availability too.

The hard deadline limits quotes, purchased stays, and extensions. The selected plan cannot fall through to a more permissive plan merely because its departure limit is exceeded. The deadline is retained on the session, so a later rate edit does not silently move an existing session's departure time. Existing location overstay detection and departure behavior remain in effect; a deadline is not evidence that a car physically left.

Test entry just before opening, at opening, before and at closing, after-midnight arrival, a stay ending exactly at the deadline, and one minute beyond it. Include daylight-saving transitions when relevant. Do not use grace periods or overage as permission to sell parking past the hard deadline.

Use Adjust pricing on mobile or the location section of the web Rates page for temporary changes. These affect one location only; editing a shared plan affects all assigned locations. Read get_location_pricing, then preview_location_pricing, then obtain the normal tool approval through adjust_location_pricing. Removing a group assignment affects all locations in that group. Use a temporary location adjustment to change one location for a limited time.

One eligible base/access plan prices each stay. An overlay is a plan with kind overlay and document pricing { "mode": "overlay" }; it defines eligibility and modifiers, not base tiers, tax, departure rules or caps. Its modifiers may use { "kind": "always" }. All eligible overlays stack after base modifiers in priority/ID order, before base tax and platform fees. A factor multiplies the running subtotal; a percent uses the capped base amount. A multiplier does not replace duration pricing or open a closed location. Restricted entry links remain restricted. Special-event rules retain their precedence.

Temporary adjustments contain a base preference and only explicit overlay differences from inherited group settings, with a concrete expiration within seven days and the latest revision. An ineligible base preference falls back to normal base selection. Multiple overlays compose; preview stacking explicitly. Ending or expiring an adjustment resumes current inherited rules and never resurrects an older adjustment. Conditions can change before expiration. Existing sessions retain frozen pricing terms. Eligibility shown in the UI is for a two-hour arrival now; inspect duration-specific previews. Do not describe an enabled plan as universally applied. A schedule boundary is a suggested expiration; occupancy cannot predict an end time.

Use Sessions to search by plate, location, status, or date. A session record is the operational source for its vehicle, quoted price, payment, timestamps, extensions, and related activity.

A driver may be quoted before payment is complete. Do not treat a browser confirmation alone as proof of payment; use the session and payment status shown in ParkTab. Payment methods can include cards and supported wallets through the configured processor.

Drivers can retrieve receipts from their account or receipt link when available. Before making a correction, confirm the location, plate, amount, timestamps, and payment identifier so a similarly named session is not changed by mistake.

Only authorized operator staff should issue a refund. Confirm the amount and reason, explain that bank posting time varies, and keep the ParkTab reference for follow-up. ParkTab does not promise an exact bank settlement date.

In location settings, open Staff tools & equipment and Session messaging. Managers maintain the location's messaging policy and fixed messages. Off blocks new operator messages and parker replies; existing history remains readable to authorized participants. On allows custom messages and reusable templates. Fixed messages only requires staff to choose a current approved message without changing its text; parkers can still write their own replies. Add at least one fixed message before staff can send in fixed mode.

Messaging is only for urgent communication about the parking session, such as asking a parker to move a car before the lot closes. Do not use it for casual conversation, promotions, or marketing. Turning messaging on does not grant staff permission: the sender also needs Send messages for that location.

In the operator app, open the session's messaging action, or use Send messages from the location's session list and select the sessions to contact. Select between 1 and 50 sessions. Choose an approved message when fixed mode is enabled; otherwise write an urgent session message or use a template.

Use the saved notification channel, SMS or WhatsApp, with optional push; push-only is also available. Phone delivery needs a saved or associated notification number, and push needs an eligible registered device for that session. The saved phone-channel preference is respected; ParkTab does not silently switch SMS and WhatsApp. Review each session's send result because missing contacts, opt-outs, unavailable devices, or delivery failures can prevent notification. A bulk send fans out individual messages, not a shared group chat, and success for one recipient does not prove every recipient was notified.

Each parking session has its own thread. Parkers open the notification's session link or the app's session messaging screen to reply. Operators can view messages and mark them read; unread counts help identify sessions awaiting attention.

Replies to the SMS or WhatsApp notification are not ingested as session conversation messages. Direct parkers to the session page or app. The separate valet READY retrieval command and SMS STOP, START, and HELP handling remain available; a normal conversational reply must not be described as a retrieval request.

On the operator app's cash receipt flow or session messaging contact form, use Add notification number, enter the phone number with country code, choose SMS or WhatsApp, and save. This stores a notification contact on the session; it does not assign the session to the account associated with that number. Correct an incorrect number before sending. Contact editing also requires the location's messaging permission.

Check both the location's messaging mode and the user's location access. Managers and owners inherit Send messages; a worker needs an explicit grant in Users & Roles. A grant does not create worker access or permit its holder to grant access to others. If fixed messages changed while a sender was composing, refresh and select the current message again. Never assume a failed or unconfirmed send reached the parker.

Open Get paid and complete the processor onboarding steps for the operator account. Required business and bank information is collected by the payment provider. Payout availability depends on the provider account being verified and enabled.

Reports and payment views help reconcile sessions, gross charges, fees, refunds, and payouts. Date ranges and operational timestamps can differ from the processor payout date, so use the same basis on both sides of a comparison.

Invite users from Users & Roles and assign the least access they need. Review roles when responsibilities change, and remove access promptly when someone leaves the organization.

A ParkTab role controls what a teammate can do in the product. Payment-provider verification controls whether money can be processed or paid out. Fix the system that owns the blocking status.

In Users & Roles, use Additional permissions to grant a worker Manage shift team or Send messages independently at a location. The teammate must already have worker access there. Managers and owners inherit both capabilities, and ParkTab admins have administrative access. Removing an explicit grant does not remove a capability inherited from a manager or owner role. A delegated capability does not allow its holder to change other people's permissions.

Send messages also depends on the location's Session messaging mode. Off blocks sending even for a permitted user; Fixed messages only limits staff to approved messages. See Manage location workers and shifts and Send urgent parking-session messages for the operational steps.

In the operator app, select the location and open Shift team from the location header. Managers and owners inherit Manage shift team; workers need that additional location permission. A missing button can mean missing access, not that the location has no shifts.

Current team shows current and upcoming shifts for today. Working now counts distinct workers whose recorded shifts include the current time. Shift history lets you choose a date and browse previous or next days, including completed shifts. All dates and times use the location's timezone; an overnight shift can appear on both days it overlaps.

Choose Add shift. Reuse a recent worker, search previous workers, select an existing user from the operator account, or add a named worker without a ParkTab account. Enter a label and the shift's start and end times, then save. The end must follow the start; check the end date for an overnight shift and the displayed UTC offset around daylight-saving changes.

Linking a worker to an account records who the worker is; it does not invite that person, grant location access, or change their role. A named worker can have shifts without needing an account or device.

Use Edit shift to correct the worker, label, or times, or remove an incorrect shift. If another person changed the shift, refresh the latest record before retrying so you do not overwrite their work. ParkTab retains an audit history of creation, edits, and removal with who changed it and when. The date-based Shift history view is the staffing record; do not confuse it with the underlying change audit.

Recorded shifts describe staffing intervals; they are not proof of a worker clocking in, a payroll calculation, or a payment. Valet alert duty and temporary runner access are separate features. Adding or ending a shift does not itself subscribe a device to valet alerts, revoke a runner link, or grant messaging permission.

In Users & Roles, a location manager can grant a worker Manage shift team under Additional permissions. Send messages is a separate grant. Grants apply to that location and require underlying worker access. Someone with a delegated capability cannot delegate it onward; managers and owners retain that responsibility.

Valet operations track vehicle intake, ticket or claim identity, vehicle status, requests, and return. Staff should advance the vehicle through the actual operational stages so the driver-facing status stays accurate.

When a driver requests their vehicle, verify the claim path before releasing it. Use the current request and vehicle record rather than relying only on a name or verbal description.

Use Enforcement to check whether a plate has an applicable active session or authorization. Confirm the plate, location or zone, and effective time before taking action. A typo or wrong zone can make a valid stay appear unauthorized.

Citations and payment records are separate from ordinary parking sessions. Record the evidence and identifiers required by the operator policy, and use the citation-specific flow for review or payment.

Create location and access-plan QR codes from QR codes. The encoded value is a URL, so print tests should be scanned at the intended size and distance. Replacing signage is necessary if its destination must no longer be shared.

Supported payment hardware must belong to the correct operator and location context. Confirm network connectivity, processor registration, and the selected location before troubleshooting an in-person transaction.

ParkTab integrations use authenticated APIs, including GraphQL operations and realtime subscriptions where provided. ParkTab does not currently promise arbitrary outbound HTTP webhooks, so integrations should use the documented interfaces rather than assuming webhook delivery.

Store API credentials only in approved secret storage, grant the narrowest permissions possible, and rotate credentials that may have been exposed. Never place a server secret in browser or mobile client code.