Requesters

Everyone who raises tickets — by email, chat, the widget, the portal or through your team.

Customers

Everyone who raises tickets — by email, chat, the widget, the portal or through your team. A customer uses no seat.

Groupings and manager

Department, Site, Unit and Company are chosen from lists kept in Administration → Customer groupings (company stays free text until you add the first one). Rename any of them in Settings → Workspace → Names.
Give a company its email domains (the @ button on its row) and anyone new who writes in, signs in or is synced or imported from those domains is filed under it — sub-domains too. People with no company yet are filed straight away; nobody already in one is moved.
VIP customers can have faster SLA targets of their own: Settings → SLA policies → Customer and VIP targets → choose "Every VIP". A customer's own contract still comes first.
Tickets, reports and automations can be filtered and grouped by them, and skills-based assignment can route on them — a member skilled in “Chennai office” gets those customers' tickets.
A manager is another customer. They approve requests for services that ask for the manager's approval.
VIP can drive an automation — “Customer is VIP → set priority High” puts them on your faster SLA tier.

Import takes a CSV or Excel file, one person per row with a header row. Columns are matched by name and can be changed before importing.
Each row is added, or updated by email. A blank cell keeps what is already stored, so a sheet of names and departments never wipes anyone's phone number.
A manager is matched by their email — and added if they are not here yet — whatever order the rows are in.
Rows that cannot be imported (no email, a duplicate) and any warnings are in a problems file to fix and import again.
With an identity provider, directory sync keeps this list current instead — Settings → Single sign-on.

Devices on a customer's page are the assets assigned to them; their tickets show them too.
Inactive means your directory says they have left: tickets stay, portal access ends.

Erase data is different from leaving: it permanently replaces their personal details with placeholders, for a data-protection request.