Sign inTry free for 14 days

Configure visit reasons ​

Visit reasons record what a visit was actually about. While serving a client, the operator tags the visit with one or more reasons from a list you define — tagging is mandatory, so every completed visit carries at least one — and the tags feed your visit-pattern reporting. Each branch curates its own list, which starts empty.

Prerequisites ​

  • An organisation admin sign-in, or the Location Manager role for the branch. Visit reasons are managed in the location manager console, and on the branch configuration page's Services tab, beneath the services panel.

Manage the catalogue ​

  1. Open the branch, then Services → Services & Reasons. A new branch shows "No visit reasons configured for this location."

    Services & Reasons tab with the Add reason action and the branch's visit reasonsOpen full-size screenshot (new tab)

  2. Click Add reason and type a name (up to 100 characters, unique within the branch — comparison ignores case). New reasons are appended to the end of the list; the list keeps insertion order, with no reordering.

  3. Rename a reason at any time. Operators see the new name on their next console load, and historical visits tagged with it display the new name too.

  4. Deactivate a reason you no longer offer: it disappears from the operator picker but stays in the list with an Inactive badge, and all history is kept. Reactivating brings it back (subject to the same name-uniqueness check).

  5. Delete removes a reason permanently, after a confirmation: "This reason will be permanently removed. Historical visit data will retain the reason name. Continue?" Past visits keep the name as frozen text, so reports stay meaningful.

What operators see ​

While serving, the operator console shows a visit-reason multi-select fed by your branch's active reasons. The Complete service button stays disabled until at least one reason is selected, and an "Other" option with free text (up to 100 characters) covers anything not in the list. The operator side is covered in Daily operations.

Result ​

Every completed visit at the branch is tagged with the reasons that match your real service mix, deactivation and deletion never lose history, and your reporting reflects what clients actually came for.

Common problems ​

  • "must be unique within the location" — another active reason already has that name (case-insensitive). Rename or reactivate the existing one instead.
  • An operator cannot complete a visit — no reason is selected yet; the console says "Select at least one visit reason before completing." Make sure the branch's catalogue holds the reasons your operators actually need.
  • A change is not visible to an operator — the picker refreshes on the operator's next console page load.