Skip to content

The service desk kiosk

/portal. Needs portal.client.

A self-service kiosk where somebody identifies themselves and then chooses what they need. Put it on a tablet at the service desk with a card reader.

Tap a card on a connected reader. The kiosk recognises it, flashes a verified ID card, and greets the person by name.

Or type a username and press Continue.

When done, press Finish. That returns the kiosk to the entry screen and ends the session, so the next person never sees the previous person’s records.

Typing a username proves nothing, so it is disabled by default in production. People tap their card instead.

If your kiosk sits somewhere physically supervised and you want username entry, an administrator can enable it with PORTAL_USERNAME_ENTRY=1.

Either way the session is short-lived, fifteen minutes by default, and only ever shows the records of the person who signed in.

  1. Pick the device. The kiosk lists devices already linked to them. If theirs is not listed, they choose “My device is not listed” and type the serial.
  2. Choose a repair type. Each shows its coverage, so they know before handing the device over whether this is likely to cost anything.
  3. Describe what happened.
  4. Tick “I need a loan device” if they want a loaner.
  5. Lodge.

They are told the outcome immediately, including the loan number if one was assigned, and that they will be emailed when it is ready.

At the desk, the submission arrives with a sticky toast so it is not missed.

Their repairs with current status, so they can check progress without asking anybody.

Two kinds of request.

Password reset. The fastest path is self-verification: the person taps their own card, or types its number, and goes straight to a “set a new password” screen. No staff time at all.

If they cannot, they choose “Request reset (staff verifies)” and an ICT staff member approves it at the desk. The kiosk shows a waiting spinner and updates automatically when approved or denied.

Something else. They describe what they need and a staff member verifies their identity and helps.

Password resets go through your LDAP connector and are subject to your directory’s password policy, so a password your directory rejects is rejected here with the directory’s own message.

Buy a consumable: a bag, an adapter, a cable.

  1. Pick the product and quantity.
  2. Verify it is them by tapping or entering a card, or entering a password.
  3. Confirm.

A confirmation is emailed to the student’s parents. That message cannot be switched off, because a parent is owed a receipt for money taken.

Opens the help centre.

The arrangement that works:

  • A tablet on a stand, at the counter, in full screen, showing /portal.
  • A USB card reader attached. Most act as keyboards and need no configuration.
  • A sign saying what it is for. “Book a repair here” gets used; an unlabelled tablet does not.
  • Somewhere staff can see it, both so people get help if they are stuck and because that supervision is what makes username entry defensible if you enable it.

A kiosk absorbs three categories of desk traffic: booking repairs, checking status, and password resets. Between them that is most of the queue at a school ICT counter.

The self-verified password reset is the one to point out to your team. It takes a staff member out of the loop entirely for the single most common request in any school.

SettingEffect
PORTAL_USERNAME_ENTRY1 allows username-only entry. Off by default
PORTAL_SESSION_TTL_MSSession lifetime. Default 15 minutes

Repair types and their coverage come from workflow. Loan assignment comes from loan groups. Products come from stock.