Organize multi-department B2B support with Divisions, teams, roles and queues

A B2B customer may need help from several departments while expecting one coherent service experience. Supportbench provides Divisions, agent roles, teams and queues to organize that work within the same account. These controls answer different questions: which operational area owns the work, who can act on it, which people provide coverage and where cases wait or are assigned. Design them together so a customer handoff keeps its history, ownership and service commitments clear.

Choose the correct control for each decision  ·  Plan around work, not only the organization chart  ·  Create only the Divisions the operation needs  ·  Define staff access, teams and profile assignment  ·  Connect intake to the intended queue and owner  ·  Make cross-department handoffs accountable  ·  Review the customer experience independently  ·  Run a useful multi-department operating review  ·  Verify the whole route before relying on the design

Choose the correct control for each decision

A Division is not a separate Supportbench account or a complete security boundary by itself. A team is not a customer organization. A queue is not an SLA promise. Keeping these distinctions clear makes the system easier to maintain as products and departments change.

Plan around work, not only the organization chart

1. List the support services you actually deliver: product areas, regional coverage, specialist investigations or separate customer programs. Identify where their behavior genuinely differs.
2. Map how a request arrives, which Company/Contact should be recognized, which Division and queue apply and who accepts ownership.
3. Identify what must remain shared, such as the customer relationship and relevant case history, and what requires controlled access. Do not promise isolation based on department names alone.
4. Record service hours, handoff responsibilities and the next customer-update owner. Different time zones do not automatically create continuous coverage.
5. Choose the reporting questions each supervisor needs answered. Define which work belongs in a department view and which needs an account-wide review.
6. Agree one owner for the configuration map and a process for reviewing it when a department, queue or service commitment changes.

Create only the Divisions the operation needs

1. Open Settings → Organization → Divisions with the appropriate Division administration permission.
2. Choose New Division or review an existing Division. Use a clear Name and Description.
3. Choose Parent division only where the child belongs under a root Division. The supported hierarchy is not an arbitrarily deep organization tree.
4. Set Display order for a readable list. Review Default email, Default KB community and Asset categories against the actual service.
5. Review Active division, then choose Save Changes. Reopen the record and inspect its saved defaults and hierarchy.
6. Check relevant case choices and configuration after refresh. Creating a Division does not automatically create its queues, staff roles, portal or workflow rules.

A default email selects an already configured sender identity; it is not an inbound mailbox route. A default KB community does not by itself publish content or establish a dedicated customer portal. Maintain those objects through their own configuration guides.

Define staff access, teams and profile assignment

1. Design the agent role around the required job and case scope using the related role-design guide. Test the required case-view and action permissions.
2. In Settings → Organization → Roles, review Divisions carefully: both an empty selection and all-selected selection represent unrestricted scope. A deliberate proper subset is needed for a narrower selection. Selected roots include descendants, and own-assigned or uncategorized cases can follow separate admitted paths; test the actual records.
3. In Settings → Organization → Teams, configure the intended team identity, hierarchy, working hours/time zone and relevant holiday or review-group settings.
4. In Settings → Organization → Agents, open each intended profile and review Assignment & routing: Division, Role, Primary team and Manager where applicable.
5. Save and test with a representative staff identity. Review an included case, an excluded-Division case and an own-assigned case separately.
6. Confirm the team’s working pattern and absence cover. Staff access to a case and willingness or availability to own its next action are separate facts.

Do not promise that internal discussions are visible only because of one Division setting. The viewer’s case access and the relevant discussion permissions still matter. Similarly, adding a manager does not replace the role and reporting-scope review.

Connect intake to the intended queue and owner

1. Open Settings → Organization → Queues and configure the queue’s team/global scope, membership and intended hierarchy.
2. Review automatic assignment separately: eligible agents or teams, availability rule and applicable working hours. A queue name does not establish these decisions.
3. Configure the actual intake path through the relevant email route, portal form, chat widget or integration guide. Confirm how the case receives the intended Division/customer context.
4. Review the workflows that select, change or override routing. Use precise conditions, explicit exceptions and the intended priority/Stop processing behavior.
5. Create approved matching and nonmatching test requests through each channel you will use. Check the resulting Company, Contact, Division, queue and owner.
6. Repeat an outside-hours or unavailable-agent example and record who monitors the unassigned work. Do not assume that configuring team hours automatically suppresses every assignment path.

If two workflows affect the same intake, inspect the final case result and the responsible rules. A successful first assignment does not prove that a later update cannot change it. Use the actual case history and available evidence to understand the result before adding another broad rule.

Make cross-department handoffs accountable

A handoff should transfer enough context for the next person to act while keeping a clear customer-update owner. Use the supported assignment, escalation, discussion and task functions for the situation; do not treat moving a queue or changing a Division as a complete communication process.

1. State the customer’s operational impact and the specific help needed. Link the relevant case evidence, affected asset and prior attempts.
2. Identify the receiving team or person and the action they should accept. Check that they can access the required case and customer context.
3. Record who owns the next customer update and when it is due. A mention is useful for attention but does not by itself establish a task deadline or accepted ownership.
4. After the handoff, verify the case’s saved queue/owner and current SLA target. Schedule resolution can depend on the actual queue path.
5. When specialist work returns, summarize the finding, remaining work and accepted owner. Use the appropriate de-escalation/return path rather than leaving the customer-facing agent to infer the result.

Keep distinct customer cases when they need different owners, access or promises. A common Company or similar symptom does not prove that the records should be merged. Use account history to investigate the relationship before consolidating work.

Review the customer experience independently

Decide whether the customer needs one shared portal or a separately configured experience. Review the portal’s included Divisions, sign-in rules, Contact/Company case authorization, knowledge topics and article restrictions. A Division default or public topic alone does not establish every part of customer access.

Use approved test identities and records. Review required and excluded access, article publication state and the saved portal result together. Do not use real private customer data in public documentation screenshots.

Run a useful multi-department operating review

1. Give each supervisor an actionable view of their work with explicit filters and ownership. Include unassigned or approaching-commitment work where that is part of their responsibility.
2. Use an account review to examine relevant open and recent cases across the customer relationship. Read the original evidence before calling repeated symptoms one underlying defect.
3. When scheduling exports, review recipient eligibility and the resulting data scope. A department-specific title does not guarantee that a report contains only that department’s records.
4. Compare KPIs using the same definitions, periods and eligible populations. A difference in case complexity or coverage may explain part of a difference in measured duration.
5. Review recurring handoff failures and turn verified resolutions into reusable knowledge with the right audience and review path.
6. Revisit the configuration map when a team, service or account owner changes. Update routing, access, schedules and documentation as a coordinated change.

Verify the whole route before relying on the design

If one check fails, correct the configuration that owns it. A missing queue participant, an unrestricted role, a portal topic exclusion and an inaccurate report filter are different problems. Record the observed case/article IDs and context so the next administrator can reproduce the issue.

Continue learning

• Reference Division configuration
• Design and test agent roles
• Reference staff permissions and Division scope
• Configure teams and availability
• Configure queue assignment
• Manage escalation and return
• Verify working hours and SLA calendars
• Review customer portal access
• Use Company and Contact history
• Schedule operational reports