Ticket Pools

Lodgestory CRM › Settings › Ticket Pools

Stop telling your inbox who handles a ticket. Build a pool of teammates, set the rules once, and every new ticket lands on the right person — at the right hour, with the right workload, on the right shift.

TL;DR

• What it is — a named group of teammates plus a rule for who gets the next ticket. Whenever a ticket is created from a bot journey or your team uses pool-based routing, Lodgestory picks one member from the pool and assigns them.
• Who it's for — Account Owners, Admins, and Super Users configure pools. Every team member can be a member of one or more pools.
• Top outcome — ticket-after-ticket distribution that's fair, schedule-aware, timezone-aware, and resilient when somebody's off — without any spreadsheet, lookup, or human dispatcher in the loop.

At a glance

How to find it

Two ways in:

1. Settings → Ticket Pools (in the Users section, next to Teams).
2. From Settings → Ticket Workflows, the header has a Manage Ticket Pools button — handy when you've just finished designing a workflow and want to decide who handles the tickets it produces.

Direct URL: https://app.lodgestory.com/crm/settings/ticket-pools

[SCREENSHOT: ticket-pools-landing.png — list of pools with active/off badges and a one-line summary]

What is Ticket Pools?

The problem it solves

Once your team is more than two or three people, "assign this ticket to so-and-so" stops scaling. Mornings need different people than evenings. Senior staff should take more load than juniors. Somebody is always off — vacation, lunch break, shift change. Manual assignment turns into a tax on whoever's nearest a keyboard.

A pool is the thing in the middle. You define who's in it, when each member is on, and how Lodgestory should pick among them. After that, every ticket created with that pool just lands on the right person. The result is a routing layer that's predictable, fair, and doesn't ask a human to think about it twice.

What you get

• Pools that belong to your organisation. Create as many as you need. Front Desk, Maintenance, VIP, Night Shift — each with its own roster and its own rules. A teammate can sit in several pools at once; pools never compete or collide.
• Two ways to know who's "on." Either define an hour-of-day schedule (different members for 9 AM, 10 AM, 11 AM…) or honour each member's Available for chats toggle from the Team Members page. Switch between the two anytime; the schedule survives toggling.
• Four strategies for picking the next member.
  • Take turns — round-robin across whoever's currently on.
  • Whoever has the fewest open tickets — load-balance to the least busy.
  • Random — pick uniformly at random; cheap, fair over time.
  • Take turns by capacity — round-robin weighted by a per-member capacity number, so a senior with capacity 3 gets three tickets for every one that goes to a junior with capacity 1.
• A timezone you actually mean. Each pool stores its own timezone. The 9 AM slot in a pool set to Asia/Kolkata is 9 AM Kolkata, not 9 AM in some random server clock. Run a pool for your New York team in America/New_York and a pool for your Singapore team in Asia/Singapore on the same workspace; both behave correctly at their own local hours.
• A warm-handoff fallback. If the current hour has nobody scheduled — or in availability mode, nobody's online right now — Lodgestory falls back to whoever was picked most recently from this pool. The ticket still gets an owner; the team isn't blocked by an unfilled slot.
• Visual hour editor. The Schedule tab shows 24 rows, one per hour of day. The current hour is highlighted with a "Now" badge that updates as the clock moves. Each row shows the assigned members as chips, an Add member picker, and a Copy to all hours shortcut for "this group is on around the clock."
• A live preview at the top. "If a ticket came in right now, it would go to: Priya." One sentence above the tabs, computed against the current hour and the next-pick rule, so you can sanity-check your schedule without firing a test ticket.
• Per-member capacity (when you need it). When the strategy is Take turns by capacity, each member has a capacity number. Capacity 1 is the default; higher numbers take more share of the work over time.
• Import from a team. If you already have a team set up under Teams, the Import from team button creates a new pool with the same members in one step. The new pool stands on its own afterwards — changing the team later doesn't change the pool.
• Pool-aware ticket creation. Bot journeys can now point their Create Ticket step at a pool instead of a fixed person. The pool picks at the moment the ticket is created, so the assignee reflects who's actually on at that hour.
• Audit on every routed ticket. Every ticket that came in through a pool carries a small via Pool: badge in its detail view, and the tickets list has a Pool filter so you can review everything a given pool routed.

How it's different

• Time-of-day, not time-windows. Most routing tools ask you to draw start/end ranges. Lodgestory uses one row per hour of day instead. A user picker on each hour is faster to scan, faster to edit, and removes the "what if two ranges overlap" question entirely.
• No empty pools, ever. Lodgestory enforces a minimum of one member. You can't accidentally save a pool that would silently fail to route anything. The same rule applies when removing members — the last member can't be removed; you're told to retire the pool instead.
• Retire, don't delete. Pools have an on/off switch. Turning a pool off keeps the historical record intact — tickets that came through the pool still show the audit badge, your reports still slice cleanly. The pool simply stops being usable for new routing until you turn it back on. There's no destructive delete button by design.
• Warm-handoff fallback by default. Other routing systems will either reject a ticket when the current slot is empty or quietly drop it. Lodgestory hands it to the most-recently-active member of the pool. Tickets keep flowing; somebody owns every one.
• Pools are independent of chat assignment. Pools route tickets only. They don't touch chat assignment, don't change who's "primary" on a chat, and don't compete with the round-robin you already have on Teams. You can use teams for chat visibility and pools for ticket routing on the same chats without any interference.

Customer scenarios

• Day and night shift, same team, two pools. Front Desk — Day has six members assigned across hours 8 AM to 7 PM in Kolkata; Front Desk — Night has three members across 7 PM to 8 AM. Both use Take turns. A bot journey creating a maintenance ticket at 11:42 PM lands on whoever's on the night shift, fairly distributed across the three.
• One pool, capacity weighting. A small support team of four — two seniors, two juniors. Strategy is Take turns by capacity, with the seniors at 3 and juniors at 1. Over 80 tickets, seniors handle about 30 each and juniors about 10. Fairness isn't equality; it's matching capability.
• Availability-driven pool. A pool of ten field engineers across many timezones. The pool is set to When they mark themselves online — engineers flip Available for chats on Team Members at the start of their shift; the pool only routes to whoever is currently online. Strategy is Whoever has the fewest open tickets, so the least-busy on-shift engineer takes the next call-out.
• One-person VIP routing. A VIP Concierge pool with two members, no schedule, strategy Take turns. Every VIP ticket cycles between the two without anybody planning a rota.
• Multi-brand workspace. A multi-property operator runs three pools — Luxury — Concierge, Mid-market — Front Desk, Budget — Self-service. Each pool has different members, different hours, and different strategies. Bot journeys on each brand's channel pick the matching pool when they create tickets.

How it fits with the rest of Lodgestory CRM

• Team Members is the source of truth for who exists. A pool can only contain current team members; remove a person from your organisation and Lodgestory removes them from every pool they were in.
• Teams seed pools through the Import from team shortcut. After import, the pool is its own object — changes to the team don't propagate, and vice versa.
• Ticket Workflows decide what a ticket is about (issue and sub-issue). Pools decide who handles it. Both run independently. Every ticket carries a category from the workflow and, when routed through a pool, an audit badge from the pool.
• Bot Journeys consume pools at the Create Ticket step. When the step fires, the chosen pool picks the assignee.
• Tickets is where you see the audit — the via Pool badge in a ticket's detail view, and the Pool filter on the list to inspect everything one pool routed.
• Chat availability (on the Team Members page) is read — but never written — by the pool's availability selection mode. A teammate flipping their own Available for chats switch on Team Members instantly changes whether they're a candidate for any pool in availability mode.

Core concepts

Quick Start — set up your first pool in five minutes

Step 1 — Open Ticket Pools

In the CRM sidebar, click Settings → Ticket Pools. If you haven't created one yet, you'll see an empty state inviting you to create your first.

[SCREENSHOT: ticket-pools-empty.png — empty state with "Create your first pool" button]

Step 2 — Click Create Pool

A three-step wizard opens.

Step 3 — Name your pool

Give it a name your team will recognise. Examples: Front Desk — Day, Maintenance, VIP Concierge. You can rename it later.

[SCREENSHOT: ticket-pools-wizard-1-name.png]

Step 4 — Pick the members

A searchable list of every team member in your organisation. Tick the ones you want in this pool. A counter at the bottom shows how many you've selected; the Next button activates once you've picked at least one.

[SCREENSHOT: ticket-pools-wizard-2-members.png]

Step 5 — Choose how tickets should be shared

Four cards, each with a short explanation. Pick the one that matches how you want tickets distributed. If you also need to tweak the timezone or pick the availability mode, expand Advanced; the defaults are Asia/Kolkata (or your browser's timezone) and By hour of day.

[SCREENSHOT: ticket-pools-wizard-3-strategy.png]

Click Create pool.

Step 6 — Set up the schedule

You're dropped straight onto the Schedule tab of your new pool. Each row is an hour of day in the pool's timezone. Click the + button on any row to open a member picker; tick the people who handle tickets during that hour, then close the popover. Repeat for every hour you want covered. Copy to all hours on any row spreads that hour's selection across the full 24-row grid in one click — useful for round-the-clock coverage.

The current hour is highlighted with a Now badge that updates as time passes. Empty hours show a dashed border and Nobody's on in muted text.

[SCREENSHOT: ticket-pools-schedule.png — 24 hour rows, members as chips, current hour highlighted]

Step 7 — Save and you're done

A sticky save bar at the bottom shows how many hours you've edited. Click Save schedule. From now on, any ticket created through a bot journey or the partner API that points at this pool will route automatically.

How it works

When a ticket is created with a pool — either by a bot journey's Create Ticket step or via the partner ticket-creation API — Lodgestory does the following, fast enough that it doesn't slow the ticket creation down at all:

1. Looks up the pool and checks it's currently on. If the pool's been turned off, the ticket isn't routed (see Errors & FAQ).
2. Builds the "who's on" list. In By hour of day mode, this is the members in the current hour slot, evaluated in the pool's timezone. In When they mark themselves online mode, this is the members whose Available for chats toggle is currently on.
3. Picks one using the pool's strategy:
   • Take turns picks the member who was picked least recently in this pool.
   • Whoever has the fewest open tickets counts the currently open tickets each member is handling from this pool, picks the lowest, and breaks ties by "least recently picked."
   • Random picks uniformly.
   • Take turns by capacity picks the member with the lowest tickets handled so far divided by capacity — over time, this matches the configured ratio.
4. Falls back to a warm handoff when "who's on" is empty — no scheduled members in the current hour, or nobody currently online. The fallback picks the most-recently-picked member of the pool regardless of schedule or availability. The ticket gets an owner; the system never silently drops it.
5. Records the pick. Lodgestory updates the member's "last picked" timestamp and their lifetime tally for this pool, then assigns the ticket. From the ticket's point of view, it has a normal assignee — the only difference is the via Pool audit badge that surfaces on the ticket detail view.

Two simultaneous tickets that hit the same pool at the same moment are picked safely — Lodgestory ensures the two go to different people when the strategy and the on-list allow for it. You won't get duplicate assignments from a race.

Two invariants you can rely on

1. Every pool has at least one member. Lodgestory refuses to save an empty one, and refuses to remove the last remaining member. If a pool becomes irrelevant, turn it off instead.
2. Every ticket routed via a pool has a real assignee. The warm-handoff fallback closes the only window where a ticket could otherwise end up unassigned. You will never see a via Pool ticket with a blank assignee.

Features in depth

The Basic tab

The Basic tab on a pool's detail page lets you change the four core settings.

• Pool is on / off. When off, the pool stops routing new tickets. Existing assignments and the audit history are untouched. Turning it back on resumes routing immediately. This is the supported way to retire a pool.
• Name. Up to 100 characters. Pool names must be unique within your organisation; Lodgestory will tell you if there's a collision when you save.
• How should tickets be shared? The strategy. You can switch between the four at any time; the next ticket picks under the new rule.
• When are members available? The selection mode. Switching from By hour of day to When they mark themselves online doesn't delete your schedule — the hour rows are preserved so you can switch back without losing your work. While in availability mode, the schedule simply isn't consulted.
• Timezone. The pool's timezone. Used only by By hour of day mode to evaluate the current hour. Use a standard IANA name — Asia/Kolkata, America/New_York, Europe/London, UTC. Changing it instantly retunes which hour is "now" for the pool.

The Members tab

A card per member, with their name, email, lifetime tickets-routed count, and the time since they were last picked. The Add member button at the top opens a search-as-you-type picker over the team members who aren't already in the pool.

Capacity is shown as a small editable badge on each card — but only when the pool's strategy is Take turns by capacity. Under any other strategy, the capacity setting is irrelevant and Lodgestory hides it to keep the view clean.

The trash icon on a member card removes them. If the pool currently has exactly one member, the icon is disabled and a tooltip explains why — add another member first if you want to remove this one, or turn the pool off.

The Schedule tab

Twenty-four rows, one per hour, labelled in 12-hour clock (12 AM, 1 AM, …, 11 PM). Each row:

• The chips show who's currently on for that hour, with each member's avatar and first name. Click the small X on a chip to remove that member from the hour without opening the picker.
• The Add (+) button opens a popover with a checkbox list of every pool member, a search box, and Select all / Clear shortcuts. Tick to add, untick to remove; close the popover to stage the change.
• The Copy icon copies that hour's member list to all 24 hours — useful when the same people are on every hour, or as a starting point you then trim down.
• The Now badge appears on whichever hour the pool's timezone is currently in. It updates by itself as time passes.
• Empty hours show a dashed border and Nobody's on. When a ticket lands in an empty hour, the warm-handoff fallback fires.

Changes don't save automatically. A sticky bottom bar appears whenever you have pending changes, with a counter — 3 hours edited · unsaved — and Save schedule / Discard buttons. Saving replaces the schedule in one atomic step; if anything goes wrong, your previous schedule is intact.

The live preview

The strip above the tabs reads, for example: "If a ticket came in right now, it would go to: Priya Singh." It updates every minute and mirrors the pick that would happen in Take turns mode against the current hour. When the current hour is empty and the pool would fall back, the preview tells you so. Use this to sanity-check before you connect a bot journey.

Import from team

The list-page button Import from team opens a two-step dialog. Pick a team from your organisation; give the new pool a name and optionally tweak strategy, timezone, or selection mode under Advanced. Lodgestory creates the pool, copies every current member of the team into it, and drops you on the new pool's schedule tab.

Two things to know:

• The import copies the team's roster at that moment. The new pool isn't linked to the team afterwards — adding someone to the team later won't add them to this pool.
• A team with zero members can't be imported; you'll see a friendly error.

Pools in bot journeys

The Create Ticket step in a Bot Journey now has two ways to set the assignee:

• Send to a specific person. The classic behaviour — pick a teammate from a dropdown.
• Send via a pool. Pick a pool; at run time, the pool picks the actual assignee.

Switching between the two is a single click; only one is active per node. If the pool you select is later turned off, the journey continues (it doesn't crash) — the chat receives a clear message naming the reason (see Errors & FAQ), and the journey's next node runs normally. The same is true if the pool ends up with no members (which shouldn't be possible while the pool is on, but Lodgestory guards against it anyway).

Pool-routed tickets in the inbox

Every ticket that came in through a pool has a small via Pool: badge under the assignee on the ticket detail view in Tickets. The same view lets you filter the ticket list by pool — a Pool dropdown appears in the filter bar whenever you have at least one pool, with the pool's name in the dropdown. Pick one to see every ticket routed via that pool, period.

Roles & permissions

If a non-admin opens the Ticket Pools URL directly, Lodgestory redirects them back to the workspace. Pools are administrative configuration; viewing or editing them requires the Admin, Account Owner, or Super User role.

Limits a user will run into

• At least one member per pool. Saving an empty pool, importing from a team with no members, or removing the last member of a pool will all fail with a clear message.
• One pool name per organisation. Two pools in your org can't have the same name. The wizard tells you if there's a collision.
• A member can only be in a pool once. If you try to add the same teammate twice, Lodgestory tells you they're already in.
• Hour values are 0–23. Schedules use hour-of-day; you can't define half-hour slots or arbitrary ranges. If your team genuinely needs sub-hour granularity, talk to support — the current product targets the 95% case.
• Schedule applies every day, not per weekday. Sunday and Wednesday share the same schedule. If you need different weekday and weekend coverage, create two pools (e.g., Front Desk — Weekdays and Front Desk — Weekends) and connect each to its own bot journey or use them on different routing paths.
• Capacity is a positive whole number. Capacity of 0 or negative isn't allowed under Take turns by capacity.

Errors & FAQ

"Pool [id] not found or inactive"

The pool you've referenced — usually from a bot journey's Create Ticket step — is either turned off (on the Basic tab) or has been removed. The bot continues the conversation; the chat sees a one-line note that the ticket couldn't be created and the journey moves on. Action: turn the pool back on, or update the journey to point at a different pool.

"Pool [id] has no members"

Defensive guard. This shouldn't normally appear because Lodgestory enforces the at-least-one-member rule. If you see it, contact support.

"User [id] is not a member of organisation [id]"

You tried to add a teammate to a pool who isn't (or no longer is) a member of your organisation. Action: confirm the teammate exists under Team Members and is part of this organisation.

"Pool must retain at least one member; delete the pool instead"

Triggered when you try to remove the last member from a pool. Pools must have at least one member at all times. Either add another member first, then remove this one — or turn the pool off (Basic → Pool is off).

"A pool named '' already exists for this organisation"

You tried to create a new pool or rename an existing one with a name that's already in use. Pool names are unique per organisation. Action: pick a different name, or rename the existing pool you wanted to replace.

Why is the Capacity column missing on my Members tab?

It's only shown when the pool's strategy is Take turns by capacity. Under any other strategy capacity isn't used, so Lodgestory hides it to keep the view focused. Switch to Take turns by capacity on the Basic tab and the column appears.

My pool says "Nobody's on" right now. What happens to incoming tickets?

The fallback fires. The ticket goes to the pool member who was picked most recently — even if that person isn't on the current hour and even if they've toggled themselves unavailable. The ticket isn't dropped, and your team isn't stuck waiting. If this happens often, your schedule probably has gaps; review the Schedule tab and the live preview.

A teammate in my pool didn't get tickets even though they're scheduled. What's going on?

Three things to check:

1. Selection mode. If the pool is set to When they mark themselves online, schedule rows are ignored — only their Available for chats toggle on Team Members matters. Confirm it's on.
2. Strategy. Under Whoever has the fewest open tickets, the load count is per pool, not org-wide. If this teammate has more open pool-routed tickets than the others, they'll be skipped until they catch up.
3. Capacity. Under Take turns by capacity, a member with low capacity takes proportionally fewer tickets. Capacity 1 in a pool where others are at 3 means roughly one ticket in four.

I deleted a teammate from my organisation. What happened to the pools they were in?

Lodgestory removed them from every pool automatically, including their hour-slot rows. If they were the only member of a pool, that pool would have refused the deletion to keep the at-least-one-member rule intact — you would have been asked to add a replacement or turn the pool off first.

Can a pool be deleted?

There's no delete button by design. Turn the pool off using the Basic → Pool is off switch. The pool stops routing new tickets immediately and your audit history stays intact. Historical tickets that came through it keep their via Pool badge — your reports continue to slice cleanly.

Why hour-of-day and not weekly hours like the Away Schedule?

We picked hour-of-day to keep the editor simple and the configuration scannable. Routing rules tend to be who's on right now questions, not when does my business open questions. If you do need different coverage on weekends, the recommendation is two pools — for example Front Desk — Weekdays and Front Desk — Weekends — connected to whichever creation paths suit each. We'll revisit if more customers need a unified weekly editor.

Connections

Team Members → Pools

Pools draw exclusively from your roster on Team Members. A teammate has to exist there before you can put them in a pool. Their Available for chats toggle on the Team Members page is the signal pools read in When they mark themselves online mode — flipping it changes pool routing instantly.

Teams → Pools

Teams seed pools through the Import from team shortcut, but stand apart afterwards. Use Teams for chat visibility and chat assignment; use Pools for ticket routing. Both can live on the same chats and same agents without stepping on each other.

Ticket Workflows → Pools

Ticket Workflows and Pools are complementary: workflows decide what the ticket is about, pools decide who handles it. Both labels live on every routed ticket. The header on the Ticket Workflows page has a Manage Ticket Pools shortcut so you can jump straight from designing a category list to deciding who'll handle tickets in those categories.

Bot Journeys → Pools

The Create Ticket step in a Bot Journey has a Send via a pool option. Switch the assignment type on the node, pick a pool from the dropdown. From then on, every ticket the journey creates routes through that pool's rules — schedule, strategy, fallback included.

Tickets → Pools

The Tickets list has a Pool filter that appears as soon as you have at least one pool. Use it to see every ticket routed by a given pool. The ticket detail view shows a via Pool: badge under the assignee for any pool-routed ticket — useful when you're reviewing why a ticket landed where it did.

API

A partner API is available for pool CRUD, member management, and schedule replacement. See the Lodgestory partner API reference for the full endpoint list; the user-facing summary:

• Create a pool with initial members in one call.
• List pools for an organisation.
• Fetch a pool with its members and schedule.
• Update a pool's name, timezone, selection mode, strategy, or on/off switch.
• Import a team into a new pool.
• Add, edit (capacity), and remove members.
• Replace the schedule in one atomic call (PUT semantics).
• Pool-aware ticket creation: pass a pool reference instead of an assignee on the ticket-create endpoint, and Lodgestory picks the assignee for you.

Pools cannot currently be deleted via the API either — the at-rest design is to retire via the on/off switch.

Changelog

• Initial release. Ticket Pools introduced with two selection modes (By hour of day, When they mark themselves online), four strategies (Take turns, Whoever has the fewest open tickets, Random, Take turns by capacity), the warm-handoff fallback, the Manage Ticket Pools shortcut from Ticket Workflows, the Pool filter and via Pool badge in the tickets list, and pool selection in the Bot Journey Create Ticket step.

Related modules & next steps

• Team Members — the people who can be in your pools.
• Teams — group your team for chat assignment, and seed pools by importing.
• Ticket Workflows — design the category list for every ticket your pool routes.
• Bot Journeys — connect a Create Ticket step to a pool so journey-driven tickets route automatically.
• Tickets — review tickets, filter by pool, and inspect the via Pool audit badge.