Team Management

Teams are the core organizational unit in RapiDesq. They control how conversations are routed to agents, how tickets are prioritized and distributed, and how your support organization is structured. This guide covers creating teams, configuring routing strategies, inviting users, managing permissions, setting agent statuses, controlling capacity, and defining business hours.

Overview

Every customer conversation in RapiDesq ultimately reaches an agent through a team. Teams connect three fundamental concepts:

• Channels — inbound conversations from the chat widget, email, or web forms are routed to a team via conversation flows.
• Routing — the team's agent selection strategy determines which agent receives each conversation, while the ticket selection strategy determines the order in which queued tickets are served.
• Permissions — user roles and permission sets govern what each team member can see and do across the platform.

A typical organization has multiple teams—for example, Billing Support, Technical Support, and Sales Inquiries—each with its own routing rules, capacity limits, ticket prefix, and business hours schedule. Agents can belong to more than one team, and supervisors can oversee multiple teams simultaneously.

Creating Teams

To create a new team:

1. Navigate to Admin > Teams.
2. Click Create Team.
3. Fill in the configuration fields described below.
4. Add team members and assign each a team role (Agent or Supervisor).
5. Click Save.

Configuration Fields

Agent Selection Strategies

The agent selection strategy controls how the routing engine chooses which available agent receives an incoming conversation. Only agents whose functional status is AVAILABLE and who have not reached their maxConcurrentPerAgent limit are considered.

BROADCAST

The conversation offer is sent to all available agents on the team simultaneously. The first agent to accept the offer is assigned the conversation.

• Best for: Small teams where speed-to-answer matters most. Every agent sees the offer immediately, minimizing wait time.
• Trade-off: Can be distracting on larger teams because every agent is interrupted for every conversation. Not recommended for teams with more than about eight agents.

ROUND_ROBIN

Conversations are distributed to agents in a circular sequence. The routing engine tracks who received the last assignment and offers the next conversation to the next agent in the rotation.

• Best for: General-purpose support teams where an even distribution of work is the primary goal.
• Trade-off: Does not account for how busy each agent currently is. An agent who just finished a quick chat and an agent who is juggling three complex issues both get the same share.

FEWEST_ACTIVE

The conversation is offered to the agent with the fewest currently active conversations. If multiple agents are tied, the system selects among them using a round-robin tiebreaker.

• Best for: Teams where conversations vary in complexity and duration. Keeps workload balanced in real time.
• Trade-off: An agent who quickly resolves conversations will tend to receive more total assignments over a shift, which may or may not be desirable.

LONGEST_IDLE

The conversation is offered to the agent who has been idle the longest—that is, the agent whose most recent conversation assignment or completion was the furthest in the past.

• Best for: Organizations that prioritize fairness and want to ensure no single agent is continuously loaded while others wait.
• Trade-off: Does not consider the number of active conversations an agent already has, only when they last received one.

SKILL_MATCH

The conversation is offered to the agent whose configured skills best match the requirements identified for the conversation (typically set by conversation flow logic or ticket metadata).

• Best for: Specialized teams where agents have distinct areas of expertise (e.g., a technical support team with specialists in networking, databases, and security).
• Trade-off: Requires upfront configuration of agent skills and conversation skill requirements. If skills are not well maintained, routing quality degrades.

Ticket Selection Strategies

When an agent becomes available and there are multiple conversations waiting in the team's queue, the ticket selection strategy determines which conversation is served next.

FIFO (First In, First Out)

The oldest waiting ticket is served first, regardless of priority or SLA status.

• Best for: Teams where all requests carry roughly equal urgency and simplicity is valued.
• Trade-off: High-priority tickets wait behind lower-priority ones if they arrived later.

PRIORITY_FIFO

Tickets are grouped by priority level—URGENT > HIGH > NORMAL > LOW—and within each priority level, the oldest ticket is served first.

• Best for: Most support teams. Ensures that critical issues are addressed before routine requests while still maintaining fairness within each priority tier.
• Trade-off: Low-priority tickets can be delayed significantly during high-volume periods if urgent tickets keep arriving.

SLA_BREACH

Tickets closest to breaching their SLA response or resolution deadline are served first, regardless of when they entered the queue.

• Best for: Organizations with contractual SLA commitments where SLA compliance is a key metric.
• Trade-off: Tickets without SLA targets may be deprioritized indefinitely. Ensure all ticket types have appropriate SLA policies configured.

ROUND_ROBIN_CONTACTS

The queue is distributed across contacts (customers) so that a single customer with many open tickets cannot monopolize agent availability. The system rotates between contacts, serving one ticket per contact before moving to the next.

• Best for: Teams where a small number of contacts generate a disproportionate volume of tickets and fairness across customers is important.
• Trade-off: Does not account for priority or SLA status. A low-priority ticket from a customer with one request may be served before an urgent ticket from a customer with many requests.

Custom Ticket Prefixes

Each team can define a ticket prefix—a short alphanumeric string that is prepended to every ticket ID generated for that team. The ticket number auto-increments after the prefix.

Ticket prefixes serve several purposes:

• Instant identification — anyone viewing a ticket ID immediately knows which team owns it.
• Cross-team communication — when agents reference tickets in internal chat or handoff notes, the prefix removes ambiguity.
• Reporting and filtering — prefixes make it straightforward to filter exports and reports by team.
• Customer communication — customers can quote a ticket ID in follow-up emails or chats, and agents can locate it instantly.

Inviting Users

To add a new user to your organization:

1. Navigate to Admin > Users.
2. Click Invite User.
3. Enter the user's email address.
4. Select a role that defines their base set of permissions (see below).
5. Optionally assign one or more additional permission sets to extend their access beyond the base role.
6. Assign them to one or more teams, selecting a team role (Agent or Supervisor) for each.
7. Click Send Invitation. The user receives an email with a link to set up their account.

User Roles

Each user is assigned exactly one platform role. The role provides a default set of permissions, but authorization throughout the platform is always checked at the permission level, not the role level. This means two users with the same role can have different effective permissions if different permission sets have been applied.

Permission Sets

Permission sets are named collections of individual permissions that can be assigned to users. They provide fine-grained control over what each user can do, independent of their base role.

Permission Format

Every permission in RapiDesq follows a resource:action format:

Creating Custom Permission Sets

1. Navigate to Admin > Permission Sets.
2. Click Create Permission Set.
3. Enter a descriptive name (e.g., "Report Viewer", "Channel Manager", "Ticket Admin").
4. Select the individual permissions to include in this set.
5. Click Save.

Once created, the permission set can be assigned to any number of users. A user's effective permissions are the union of all permissions from their base role plus all assigned permission sets.

Common Permission Patterns

• Report Viewer — reports:view + reports:export. Assign to agents who need visibility into team performance metrics without granting broader supervisor access.
• Channel Manager — channels:manage + flows:manage. Assign to a team lead responsible for maintaining chat widget configurations and conversation flows.
• User Manager — users:create + users:edit + teams:manage. Assign to an HR or operations contact who handles onboarding without needing full admin access.
• Read-Only Auditor — teams:view + reports:view + tickets:view. Assign to compliance or quality assurance personnel who need to observe but not modify.

Agent Statuses

Agent statuses control routing behavior and provide real-time visibility into your team's availability. The status system has two layers: functional statuses that the routing engine uses, and custom display labels that agents and supervisors see in the interface.

Functional Statuses

Every agent is always in exactly one of three functional statuses. These are the statuses the routing engine evaluates when deciding whether to offer a conversation to an agent:

Custom Display Labels

While the routing engine operates on the three functional statuses, your agents and supervisors see custom display labels that provide more context about what an agent is doing. Each display label maps to one of the three functional statuses.

To create custom display labels:

1. Navigate to Admin > Agent Statuses.
2. Click Add Status Label.
3. Enter a display label (the name agents see in the status dropdown).
4. Select the functional status it maps to.
5. Click Save.

Multiple display labels can map to the same functional status. This gives supervisors granular visibility into why agents are unavailable (meeting vs. lunch vs. training) while the routing engine simply sees them all as NOT_AVAILABLE.

Capacity Management

The maxConcurrentPerAgent setting on each team controls how many active conversations a single agent can handle at the same time. This is the primary mechanism for preventing agent overload and maintaining response quality.

How Capacity Affects Routing

• When an agent's active conversation count is below the team's maxConcurrentPerAgent limit, they are eligible to receive new conversation offers.
• When an agent reaches the limit, the routing engine stops offering them new conversations until they resolve or transfer an existing one.
• If all agents on a team are at capacity, incoming conversations enter the team's queue and are held until an agent becomes available. The ticket selection strategy then determines the order in which queued conversations are served.

Setting Capacity Limits

1. Navigate to Admin > Teams and select the team.
2. In the team configuration, set the Max Concurrent per Agent value.
3. Click Save. The new limit takes effect immediately for all agents on the team.

Monitoring Capacity in Real Time

Supervisors and admins can monitor capacity from the team dashboard:

• Per-agent utilization — see how many active conversations each agent has relative to the team's maximum.
• Queue depth — the number of conversations waiting for an available agent.
• Queue wait time — how long the oldest queued conversation has been waiting.

Business Hours & Schedules

Business hours schedules define when your teams are operational. They affect three parts of the platform: the customer-facing chat widget, the routing engine, and conversation flows.

Configuring a Schedule

1. Navigate to Admin > Business Hours.
2. Click Create Schedule.
3. Enter a schedule name (e.g., "US East Coast Hours", "EMEA Business Hours").
4. Select the timezone for this schedule. All start and end times you enter will be interpreted in this timezone.
5. For each day of the week, set start time and end time, or mark the day as closed.
6. Click Save.

Schedule Exceptions

Exceptions override the regular weekly schedule for specific dates:

1. Open the schedule and navigate to the Exceptions tab.
2. Click Add Exception.
3. Select the date (or date range).
4. Choose whether the exception is a closure (team unavailable all day) or modified hours (custom start and end times for that date).
5. Click Save.

Use exceptions for public holidays, company-wide events, early closures before holidays, or any other date that deviates from the normal weekly schedule.

How Schedules Affect the Platform

Multiple Schedules

You can create as many schedules as you need. Common patterns include:

• Regional schedules — separate schedules for US, EMEA, and APAC teams, each in their respective timezone.
• Team-specific schedules — a sales team operating Monday through Friday 9–5, while a technical support team operates Monday through Saturday 7am–10pm.
• Extended hours — a primary schedule for core hours and a reduced-staff schedule for evenings and weekends.

Tips & Best Practices

Routing Strategy Selection

• Start with ROUND_ROBIN or FEWEST_ACTIVE. Both strategies provide reliable workload distribution without requiring additional configuration. ROUND_ROBIN is simpler to reason about; FEWEST_ACTIVE adapts better to variable conversation complexity.
• Use BROADCAST only for small teams (eight or fewer agents) where speed-to-answer is the top priority. On larger teams, the constant notifications become disruptive.
• Reserve SKILL_MATCH for teams with clearly differentiated specializations. It requires maintaining agent skill profiles, which adds ongoing administrative overhead. Only adopt it when the routing accuracy benefit justifies that cost.

Ticket Selection

• PRIORITY_FIFO is the right default for most teams. It respects urgency while maintaining fairness within each priority tier.
• Switch to SLA_BREACH if you have contractual SLA commitments. Ensure every ticket type has an SLA policy configured, or tickets without SLAs may be perpetually deprioritized.
• Consider ROUND_ROBIN_CONTACTS if you have enterprise customers who submit high volumes of tickets and risk starving other customers in the queue.

Team Organization

• Use custom ticket prefixes to differentiate teams. When agents, supervisors, and customers reference ticket IDs, the prefix makes it immediately clear which team owns the conversation.
• Keep team sizes manageable. Large teams (more than 20–25 agents) can be harder to supervise effectively. Consider splitting into sub-teams by specialty or shift.
• Mirror your organizational structure. Create teams that reflect your support specialties or departments for intuitive routing and clear ownership.

Agent Status and Capacity

• Create custom status labels that match your workflow. If your agents have regular training sessions, add a "Training" label. If they do back-office work between chats, add a "Back Office" label. The more accurately agents report their status, the better supervisors can manage staffing.
• Set realistic capacity limits. Overloading agents degrades response quality and increases burnout. Start conservatively (3–4 concurrent chats for experienced agents, 1–2 for new agents or complex support) and adjust based on quality metrics.
• Monitor queue depth and wait times. If queues consistently grow during certain hours, that is a signal to add capacity—either by adjusting schedules, adding agents, or increasing maxConcurrentPerAgent cautiously.

Permissions and Security

• Follow the principle of least privilege. Assign the minimum permissions each user needs. Extend access with permission sets only as specific needs arise.
• Create reusable permission sets for common patterns. Instead of granting individual permissions to each user, define sets like "Report Viewer" or "Channel Manager" that can be consistently applied across users.
• Audit permissions regularly. As your organization grows and roles evolve, review who has access to what. Remove permission sets that are no longer needed.
• Use INTERNAL_USER for non-support staff. Employees who only need service desk access and team chat should not have Agent or Supervisor roles. The INTERNAL_USER role provides exactly what they need without exposing customer-facing functionality.

Business Hours

• Configure business hours before going live. Incorrect or missing business hours can result in the chat widget showing as online when no agents are available, leading to poor customer experience.
• Add holiday exceptions in advance. Set up the full year's holidays at the beginning of each year so you do not scramble to add them the day before.
• Use the SCHEDULE_CONDITION node in conversation flows to provide different experiences during and outside business hours—for example, offering an offline contact form or automated FAQ responses after hours.