Lodgestory CRM › Settings › Team Members

Team Members

Invite the people who run your inbox, give them the right roles, and flip their availability when shifts change — all from one page.

TL;DR

• What it is — the admin page where you invite members by email, edit their roles and teams, disable or remove them, send password resets, create bot service accounts, transfer account ownership, and toggle availability for chats.
• Who it's for — Account Owners and Admins manage the roster. A few actions — transferring ownership and granting Finance access — belong to the Account Owner alone.
• Top outcome — a clean roster with the right roles and correct team allocations, so chat routing, inbox visibility, invoices, and reports all behave the way you expect.

At a glance

How to find it

Sidebar: Settings → Team Members.

Direct URL: https://app.lodgestory.com/crm/settings/team-members

[SCREENSHOT: team-members-landing.png — team list with roles, teams, and availability toggles]

What is Team Members?

The problem it solves

Every other module in Lodgestory CRM depends on this one. Role wrong, and a team member can't see the chats they're meant to handle. Team missing, and bulk assignment falls apart. Availability left on for someone who's gone home, and new chats pile up on an absent agent. Team Members is the one page where that roster lives, and getting it right is the quiet prerequisite for every downstream feature — inbox visibility, bot hand-offs, invoice access, report scoping, and call access all read from here.

What you get

• A searchable roster. Every member of your organisation in one list, with their email, name, roles, teams, join date, and availability. Filter by role or team; search by name or email.
• Email invites. Enter an email, pick a role, optionally pre-fill their name and phone and slot them into teams. They get a link (valid 7 days) and set their own password — no passwords change hands. Pending invites can be copied, re-sent, or revoked at any time.
• A clear role model. Each member has one base role — Member or Admin — plus optional add-ons: Finance (invoice access, granted by the owner), Owner (exactly one, moved via Transfer ownership), and Bot (service accounts).
• Edit without drama. Update a member's name, role, Finance access (owner only), or team memberships from one dialog. Save, and the change takes effect right away.
• Disable instead of delete. Disabling a member signs them out everywhere and blocks login while keeping their roles, teams, and history intact — fully reversible. Removal is the permanent option.
• Password reset by email. Admins trigger the standard reset email; the member sets a new password themselves. Admins never see or choose anyone's password.
• Service accounts. Create the non-interactive bot identity that Bot Journeys, away messages, booking reminders, and the public API send as — no more support tickets to get a bot user.
• Ownership transfer. The Account Owner can hand the owner role to another member in two clicks, no support involvement.
• Availability you control. Set any member's status from this page using the same Online / Offline (or break) dropdown they use themselves. Great for shift handovers.

Customer scenarios

• Onboarding a new agent. Admin invites them with the Member role and the Support team pre-selected. The agent clicks the emailed link, sets their password, and starts handling chats.
• Bookkeeper needs the bills. The Account Owner edits the bookkeeper's profile and ticks Finance access. The Invoices tab appears in their Settings; nothing else about their permissions changes.
• Setting up a bot journey. An admin clicks Create service account, names it "Concierge Bot", and picks it as the bot identity in the journey's channel settings.
• Founder hands over the account. The outgoing owner clicks the crown icon on the new operator's card, confirms, and the ownership — invoices, Finance grants, API token — moves in one atomic step. The outgoing owner keeps their Admin role.
• Offboarding. Admin disables the leaver on their last day (instant sign-out everywhere), then removes them once handover is complete.

How it fits with the rest of Lodgestory CRM

Team Members is the source of truth for who exists in your organisation. Teams are groups you draw from this list. Home / Unified Inbox uses the roster when you assign or reassign a chat. Bot Journeys sends as a service account created here. Reports respects each member's role when deciding what they can export, and the Invoices tab in Settings is visible only to the Account Owner and Finance members.

Core concepts

Quick Start — add your first team member in 3 minutes

Step 1 — Open Team Members

Sidebar: Settings → Team Members.

[SCREENSHOT: team-members-qs-1-landing.png]

Step 2 — Click Invite member

A dialog opens with fields for email, role, teams, and optional name/phone prefill.

[SCREENSHOT: team-members-qs-2-invite.png]

Step 3 — Fill in the essentials

Email and a role. A typical agent only needs Member. If you're the Account Owner you'll also see a Finance access checkbox — leave it off unless this person should see the organisation's invoices.

Step 4 — Click Send invite

They receive an email with a join link (valid 7 days). If email delivery fails, the dialog gives you the link to share manually (e.g. over WhatsApp). New users set their own password; someone who already uses Lodgestory in another organisation just logs in and accepts.

[SCREENSHOT: team-members-qs-4-created.png]

Step 5 — Review and iterate

The invite sits in Pending invites until accepted — copy, resend, or revoke it from there. Once they join, open the edit dialog any time to adjust their role or teams.

What's next

• Group your agents into Teams so chats can be assigned to a whole group.
• Review who sees what in Home / Unified Inbox.

How it works

Invites are the only way humans join: the invitee proves control of the email address by clicking the link, then sets their own password (minimum 8 characters). If the email already belongs to a Lodgestory user, accepting simply attaches their existing login to your organisation — their password and other organisations are untouched. Accepting one invite automatically revokes any duplicate pending invites for the same address.

When you remove a team member, Lodgestory removes them only from your organisation — memberships elsewhere are untouched. Their chat assignments, roles, and team memberships in your organisation are cleaned up in one pass, and their historical messages stay attributed by name. Disabling, by contrast, keeps everything and just blocks login (and forces their availability off) until you re-enable them.

Features in depth

The member cards

Each card shows name, email, role badges (Owner, Admin, Member, Finance, Bot), teams, availability, and join date, plus actions: Edit, Transfer ownership (crown — owner only), Send password reset, Disable / Re-enable, and Remove.

Invite dialog

Required: email and a role. Optional: teams, name, and phone (pre-fills their signup). The Finance access checkbox appears only for the Account Owner. The link expires in 7 days — resend from Pending invites if it lapses.

Edit dialog

Name, role, and teams. Role and team selections are the full intended state — switching the role replaces the old one. The Account Owner additionally sees the Finance access toggle here; unticking it revokes invoice access. If the member being edited is the Account Owner, their owner role is fixed and kept alongside the base role you select.

Transfer ownership (Account Owner only)

Click the crown icon on the target member's card and confirm. In one atomic step: they gain the Owner role (keeping their existing roles), you lose it (keeping your Admin/Member role — you're granted Admin if you'd otherwise be left with none). Two security side-effects happen in the same step: the organisation's API token is rotated (the old owner has seen it — update any integrations with the new token from Settings → API Token), and both of you are signed out everywhere so your sessions pick up the new access. Not available for service accounts, disabled members, or yourself. Only the new owner can transfer it back.

Service accounts

Create service account (visible to Admins and the Owner) asks for a dedicated, unused email address — use something like [email protected] — and a display name. The account is created with the Bot role, cannot log in (its password is random and never disclosed), and shows no password-reset or availability controls. It's the identity behind Bot Journeys, away messages, booking reminders, and the public API. You can create more than one (e.g. one per brand).

Finance access

An add-on the Account Owner grants (at invite time or from the edit dialog) on top of Member or Admin. It unlocks Settings → Invoices — listing, viewing, and downloading the organisation's bills, plus the pending-payment banner. Admins without Finance access no longer see the Invoices tab. Revoking works the same way: the owner unticks the box.

Disable, re-enable, remove

Disabling signs the member out everywhere and blocks every login path while keeping their setup intact — the reversible option for leave, suspension, or offboarding-in-progress. Removal permanently detaches them from the organisation. The Account Owner can be neither disabled nor removed — transfer ownership first.

Reset password

Admins click the key icon to email the member a reset code (valid 10 minutes); the member finishes at lodgestory.com/forgot-password. Admins never set anyone's password.

Availability

The status dropdown on each card is the same control each team member has in their own inbox top bar: Online, plus either Offline or — if your organisation has configured Break Types — the list of breaks. Setting it from here is the fast way to run shift changes, and the change is recorded on that member's availability timeline (attributed to you as the admin who made it). Service accounts have no availability — they're automation, not agents.

Max open chats (workflows)

The Max open chats column sets how many open chats automatic routing — team round-robin, automation ASSIGN_CHAT team modes, and bot-journey transfers to a team — may hand a member at once. Leave it blank to inherit the organisation default from the Chat routing capacity card (blank there = unlimited); set 0 for someone who should stay Online but never receive auto-routed chats (a supervisor, say). The muted open / cap figure next to the input is that member's live load.

What counts as open: a chat where the member is the primary assignee, the chat is not resolved or archived, and a workflow is still active on it. Group chats and chats on autopilot are excluded — the AI, not the member, is replying. Tickets are not counted (ticket pools have their own load rule).

Only chats with a message — in either direction — inside the activity window count. The window is set on the Chat closing & routing card (default 14 days; clear it for no window). An open chat nobody has touched for longer stops occupying a slot until it gets a new message, and the same window decides which chats are waiting in a team queue — so a team where nobody closes chats does not freeze.

The cap governs automatic routing only. Self-claim (Assign to me shows "You're at capacity" but still works), admin assignment, the ticket-owner preference, and a bot journey's transfer to a specific agent can all exceed it. When nobody in a team has capacity the chat is routed to the team with no owner and waits in the team queue — see Automations → Capacity & queues for the recipes that hand queued chats out.

A chat that has a primary assignee but no workflow (created before workflow auto-attach was switched on) does not count toward anyone's load and cannot be queued or pulled until it gets one — set the channel's new-chat and revived-chat workflows before you set caps, or members will look under-loaded.

Queues

The Queues card lists, per team, how many chats are waiting without an owner, how long the oldest has waited, and how many members currently have spare capacity. A row turns red when chats are waiting and nobody can take them. Sweep now hands waiting chats to members with spare capacity immediately (oldest first, least-recently-assigned member first) — useful right after lowering or removing caps. The same sweep runs automatically from the Dispatch waiting chats recipes.

Chat closing

The Chat closing card holds one organisation switch: Resolve chats when a workflow finishes. It is off by default. When on, moving a chat into a closing stage also marks it Resolved & closed (it leaves the open inbox, the chat.resolved webhook fires with via: "WORKFLOW"), unless the workflow's own closing rules say Never or the agent unticks Also mark chat as resolved in the stage-change note. A chat with a second workflow still active is never resolved this way. Assignees (not only admins) can reopen a resolved chat, and restarting the workflow reopens it too. Per-workflow rules — including require a disposition before closing — live in Workflow Lifecycle Stages → Closing rules.

Roles and permissions

Cross-module workflows

A. Onboarding a new agent

Team Members: invite with the Member role and pick a starting team. The agent accepts the emailed link, sets a password, signs in, and sees chats that belong to their team.

B. Standing up a bot journey

Team Members: Create service account. Bot Journeys / channel settings: select it as the bot user. Away schedules and booking reminders use the same identity.

C. Handing the account over

Team Members: crown icon on the successor's card → confirm. Billing, Finance grants, and the API token now belong to them; you keep your Admin role.

D. Shift handover

Open Team Members, flip each outgoing agent's availability off, flip each incoming agent's availability on. The inbox's auto-assignment picks the change up right away.

Limits a user will run into

Errors and FAQ

Errors you might see

FAQ

Is there an email-based invite flow?
Yes — it's the only flow. The invitee sets their own password via the emailed link; admins never handle passwords.

Can I promote a Member to Admin without recreating them?
Yes. Open the edit dialog, switch the role to Admin, save.

Why can't I (an Admin) see the Invoices tab any more?
Invoices are now restricted to the Account Owner and members with Finance access. Ask your owner to grant it if you need billing visibility.

How do I get a bot user for bot journeys or away messages?
Create one yourself: Team Members → Create service account. No support ticket needed.

How do Account Owners get created?
The person who creates the organisation is the first Account Owner. After that, ownership moves only via Transfer ownership — there is always exactly one owner grantable path, and the old owner keeps their Admin/Member role.

What happens to a member's open chats when I remove them?
The chats may end up without an assignee. An admin can reassign them from the inbox.

Can a team member be in multiple organisations?
Yes. Roles — including Finance — are per organisation: Finance access in one organisation reveals nothing in another. Removing someone from your organisation has no effect elsewhere.

API

A partner API is available for invites, member updates, service accounts, and availability. Contact your account team for access, and see the partner portal for the full request reference.

Changelog

• Aug 2026 — Max open chats (workflows) per member with an organisation default, the Queues card with Sweep now, and the Chat closing switch (resolve chats when a workflow finishes; off by default). Automatic routing now skips members at their cap; chats wait in the team queue instead.
• Aug 2026 — Ownership transfer (owner-only, in-product), service accounts (self-serve CRM_BOT creation for admins), and the Finance role: an owner-granted add-on that now gates the Settings → Invoices tab (Admins without it no longer see invoices).
• Jul 2026 — Member provisioning is now invite-only: email link, 7-day expiry, invitee sets their own password. Admin-set passwords and in-place password resets were replaced by the standard reset email. Disable/re-enable (reversible) added alongside removal.
• Jun 2026 — Availability is now a status dropdown (Online / Offline, or Online + your configured breaks) instead of a single switch, and every change is recorded to the member's availability timeline. See Break Types and Analytics → Availability.
• Apr 2026 — Initial public documentation.

Related modules and next steps

• Teams — build teams from the roster here.
• Home / Unified Inbox — where the assign and reassign controls use this list.
• Bot Journeys — service accounts created here are how automated replies are attributed.
• Reports — role-gated access draws from here.
• Break Types — the offline reasons that appear in each member's availability dropdown.