Ticket routing by business unit or brand property (multi-brand portal)

Outcome. A single shared portal serving more than one brand or business unit routes each ticket to the right team without the two brands' support queues mixing.

Workflow map Enrollment, branches and actions at a glance tickets-sla-036

flowchart TD
    A[Ticket created, brand known] --> B{Brand value?}
    B -->|brand-a| C[Rotate to Brand A support]
    B -->|brand-b| D[Rotate to Brand B support]
    B -->|unknown| E[Notify support ops, add to Needs manual triage]
    C --> F[Set routed date]
    D --> F

When to use it, when not to

• UseUse it when one HubSpot portal serves multiple brands or business units that share the object model but need separate support teams, templates, and reporting.
• UseUse it as a lighter alternative to separate ticket pipelines per brand, when the brands share enough process that one pipeline with a branch property is simpler to maintain than fully separate pipelines (check in your portal: whether your case is better served by separate pipelines instead, since HubSpot supports multiple ticket pipelines natively and that may be the more correct native mechanism if the brands' processes actually differ, not just their staffing).
• SkipDo not use it if the brands' ticket processes genuinely differ (different stages, different SLA targets); build separate pipelines instead and let each pipeline's own SLA and automation stand alone, this fiche assumes one shared pipeline.
• SkipDo not use it if there is only one brand today but "multi-brand" is a future possibility; build this when the second brand is actually live, not speculatively.