Overview

Dynamic Bays differ from static by allowing locker space to be flexibly allocated between linked (Repairs + Loans, or Repairs + Deployments) workflows. The system intelligently alternates between these linked workflows to maximise bay utilisation.

What changes vs static allocation?

• Workflows are allocated as a count, not specific bay numbers: for example, “10 bays for Repairs+Loans” rather than "Bays 1-10"
• Pairing behaviour: In a linked flow where a user both submits a repair and borrows a device, the newly vacated loan bay becomes an empty repair bay immediately, so the next user can submit a repair without waiting.
• Oversubscription protection: Certain actions may be blocked if it would consume bays expected to be required soon. For example, when an admin returns a repaired device, at least two empty repair bays (one for the returned device and another for a possible submission) and one empty loan bay (for the user to return their loan) must be available.

Administration

Creation

Workflow creation in the Portal is the same as traditional setup. Create individual workflows (Charging, Loan, Repair, Deployment). To benefit from Dynamic Bays, link a Repair with a Loan (or Deployment) workflow.

Allocation

On the Kiosk, administrators should use Allocate Workflows to assign how many bays go to each linked group. Administrators set the number of bays per workflow (or linked pair); the system distributes workflows to specific bays automatically.

Loading devices

In Load Devices, bays are shown as available or reserved. For Dynamic Bays, administrators should use Load Devices (not Drop off repairs) so empty loan bays can become spare repair bays and oversubscription protections apply.

Functionality

User flow

For end users, the experience when using Dynamic bays remains straightforward:

• Submitting a repair: user authenticates and provides details of a broken device.
• Loaning a device: if a workflow is linked, a prompt for a loan device appears.
• Depositing the repair: an appropriate bay opens for the broken device.
• Collecting the loan: an appropriate bay opens with a loan device to be collected.

The admin repair process happens while the user has access to the loan device.

• Returning the device: loaned devices are prompted to be returned before collecting a repair when required.
• Collecting a repair: user picks up their repaired device when notified or ready.

Dynamic changes

When a user submits a repair and borrows a device in the same transaction, the newly vacated loan bay immediately becomes an empty repair bay. Admins will be restricted from loading devices into workflows that would potentially cause problems for end users (e.g. occupying all repair bays, or occupying the last loan bay when a repair is due for collection by the user).

The View Tower screen can be used to see how many bays are allocated and which are currently occupied.

Recommendations

• Apply Dynamic Bays to an entire tower (or bank). Full‑tower application is recommended and typically yields the best pairing and least friction.
• Encourage repair + loan in one visit. Dynamic works best when users commonly take a loan at drop‑off.
• Or maintain a buffer: keep a small number of empty bays assigned at all times (e.g., 2+ empties per 10 bays) so repairs and returns are rarely blocked.
• Do not leave bays unassigned during operations; workflows should be assigned to all available bays, even if, for example, the loan device pool doesn't fill the locker.
• Using Drop off repairs is not recommended with Dynamic Bays. Load Devices should be used so dynamic reassignment and protections are applied.
• Watch the ratios: if loan pickups are rare, consider increasing the empty buffer/ reducing the size of the loan pool.

Admin examples

User: submit repair + borrow device (paired)

1. User submits a repair (drops off broken device) and opts to take a loaner. System opens a repair bay for deposit.
2. User loans a device. The newly vacated loan bay is immediately reassigned as an empty repair bay.
3. Result: repair capacity is preserved and the next user can drop off a repair without delay or admin involvement.

Admin: returning a repaired device

1. Administrators select Load Devices → Repair.
2. If only one empty repair bay is left, the system blocks staging to avoid starving repair capacity.
3. Free a repair bay (for example, collect a submitted repair or remove a loan device from the pool), then try again.

Admin: loading loan devices

1. Administrators select Load Devices → Loans workflow.
2. If there’s only one empty loan bay and there are outstanding loans (borrowed devices out), the system blocks to avoid oversubscription.
3. When there are empty loan bays (and no outstanding loans), loading proceeds normally.

Support

• No bays available when Loading devices: collect a submitted repair, process a user pickup, or reduce loan stock to free space.
• Contact support if you are unsure about anything, try to include as much information about the state of your locker and devices as possible (include a screenshot of your "View tower" menu where possible)