The Personal Identifier is a question-level setting in the Workflow configuration. When you mark a question as a Personal Identifier, Frontlion treats the answer to that question as the value that uniquely identifies a visitor, and it will not allow the same value to occupy the queue twice at the same time.
In practice, this means a visitor who has already checked in cannot check in again — from a kiosk, from a mobile link, or through an associate — while their first visit is still live. Frontlion blocks the second check-in and displays a message such as "Phone is already in the Queue."
Any question can carry the flag: Phone, Email, a membership number, a student ID, a case number, a policy number, or a licence plate. The flag does not change what the customer sees on the form. It only changes what Frontlion does with the answer.
When the rule fires, the check-in is rejected and the associate or kiosk sees a message in the top right of the screen.
Note: The Personal Identifier prevents duplicate active visits. It does not prevent a visitor from returning later in the day after their first visit has been served, cancelled, or marked as a no-show.
Why use it
Pros
- Accurate wait times. Duplicate tickets inflate queue depth, which pushes estimated wait times higher than reality and makes the branch look busier than it is.
- Cleaner reporting. One visitor equals one visit record, so abandonment rates, service counts, and volume-per-hour in Insights reflect real demand.
- No double-calling. Associates stop calling the same person from two different tickets, which removes the "who is actually next?" confusion at the window.
- Fairer position in line. Visitors cannot improve their position by checking in a second time on a different device.
- Fewer wasted notifications. Duplicate tickets generate duplicate SMS traffic, which costs money and annoys the recipient.
- Simple to switch on. It is a single checkbox on an existing question, and it requires no rules, no routing changes, and no new integrations.
Cons and things to watch for
- Shared values block legitimate visitors. A family sharing one mobile number, a couple sharing an email address, or a household sharing a landline will be stopped at the second check-in. Choose an identifier that is genuinely one-per-person.
- It only works if the question is answered. If the question is optional and the visitor leaves it blank, Frontlion has nothing to compare and the duplicate is allowed through. Pair the Personal Identifier with a required field.
- Typos defeat it. A visitor who enters their number slightly differently on the second attempt will not be caught. Structured types such as SMS-Enabled Phone and Email are far more reliable than free Text.
- Legitimate re-entry looks like an error. A visitor who genuinely needs a second concurrent ticket — for example, one person checking in on behalf of two people — will be blocked. Train staff on how to handle this.
- More than one identifier can over-restrict. If you flag several questions, any one of them matching is enough to block the check-in. Start with one.
- It is not identity verification. Anyone can type someone else's phone number. The Personal Identifier is a deduplication control, not a security control.
Best practices by industry
| Industry | Recommended identifier | Why | Watch out for |
|---|---|---|---|
| Retail and consumer electronics | Mobile phone (SMS-Enabled Phone) | Already collected for "we'll text you when we're ready", so it costs the customer nothing extra and stops repeat kiosk taps. | Couples shopping together on one number; keep the field required. |
| Banking and credit unions | Member or account number | One per member, stable over time, and it ties the visit to the existing record for Insights and Customer Properties. | Joint accounts share a number; consider member number plus a required name field. |
| Healthcare and clinics | Patient ID or MRN | Guaranteed unique per patient and it avoids putting a phone number on screens in a waiting area. | Do not use date of birth alone. Confirm the field's handling with your privacy team before enabling Customer Facing. |
| Government and DMV | Case, appointment, or confirmation number | Issued by you, so it is unique and typo-resistant when scanned or pasted from a confirmation email. | Walk-ins without a number need a fallback identifier such as mobile phone. |
| Higher education | Student ID | One per student, already memorized, and works across financial aid, registrar, and advising queues. | Prospective students and parents have no ID; give those queues a separate question set. |
| Telecom and utilities | Account number or mobile phone | Account number is unique per service; mobile phone is faster at a kiosk. | Business accounts send several representatives on one account number. |
| Automotive service | Vehicle Identification Number or license plate | The queue is really about the vehicle, not the driver, so one active ticket per vehicle is the correct rule. | Fleet customers dropping several vehicles need one ticket per vehicle — flag the vehicle question, not the driver's phone. |
| Logistics and parcel | Tracking or order number | Prevents one visitor from taking several tickets for the same collection. | Visitors collecting multiple parcels; consider a "how many parcels?" question instead of extra tickets. |
General best practices
- Pick one identifier per workflow. One well-chosen field is more predictable than three, and it is easier to explain to staff.
- Make the identifier question required. A blank answer cannot be matched, so an optional identifier silently stops working.
- Prefer a structured question type. SMS-Enabled Phone, Email, and Number normalize input; free Text does not.
- Use the field tooltip to reduce mistakes. Turn on Field Tooltip and explain the exact format you expect, for example "10 digits, no dashes".
- Do not flag survey questions. Surveys run after service. Flagging a survey question has no deduplication value at check-in.
- Brief your associates. Make sure staff know the message means "this person is already in line", not "the system is broken", and that they can find the existing ticket by searching the same value.
- Test: Check in with the same value twice and confirm you are blocked, then confirm a different value still gets through.
Where to go next
- How to Configure the Personal Identifier on Questions
- How to Use the Personal Identifier at Check-In
For additional support, contact the Frontlion Support Team.
0
0
Was this article helpful?
0 out of 0 found this helpful
Articles in this section
- Introduction to the Customer Indicator
- Introduction to the Personal Identifier
- Introducing Associate Interface Language
- Introduction to the Charts & Pivots Output Insights types
- Auto Call: Keeping Queues Moving Without Manual Intervention
- Service Guides: Standardizing Excellence at the Moment of Service
- Customer Properties: A Persistent Data Layer That Remembers Every Customer
- Insights - Data Dictionary
- How to Join a Virtual Waiting Line
- How a Greeter Adds a Customer to a Virtual Queue by Frontlion