Don't use Customer Based Queues

[crythias]

Why do you always say don't use customer based queues?

It sums up to this: The customer doesn't need to tell you who they are (again, via queue) in order for agents to provide services to them. It should be enough that they're authenticated and in your database.
The customer shouldn't need to select *their* queue for services that agents provide to everyone.
Almost every question posted here about "How can I restrict customers to this set of queues?" may be removed if you only provide queues for things your agents can do.

What about reporting?

If your customers have the same CustomerID, *that* is the placeholder for the "queue" you seek.

But I like the queue based grouping!

Then use CustomerBased queues. Otherwise, change your search defaults so it looks like this:

search window.png

Enable: Ticket::Frontend::AgentTicketSearch###Defaults###CustomerID
Defines the default shown ticket search attribute for ticket search screen.

But I have specific agents dedicated to specific customers

Then use Customer Based queues, if it's the only way that makes sense. Alternatively, have agent based queues and use CustomerGroupSupport to be members of the group assigned to the Queues for those agents. That way you can share agents (but tickets stay private per customer).

This is of course, only an opinion. If you have one you'd like to share, go for it.

[crythias]

Also, what happens if you have thousands of customers?

[crythias]

If you provide specific, segregated services to individual customers, you can use the Services part of OTRS to indicate that difference.

Here's something else to consider... your agents can see tickets in queues that relate in context to the agent (what do *I* need to do?) rather than customer (Who needs help?). It also means that if you have lots of agents, they don't have to modify preferences to a queue set (My Queues) because a new customer (several new customers) is/are on board. Management is reduced greatly.

I come at this viewpoint thinking of, for instance, a public service. You, random customer, come to the public service expecting personalized treatment, and while you might prefer a provider (agent/queue) of that service, the service owner doesn't generally prevent you from making the choice of agent that someone else doesn't also have the choice.

The service owner keeps the customer demographics separate. The queues are the types of things that agents *do* [plumbing]. The services are the types of things the customer owns/bought/leased/rented/have assigned to them (what is being acted upon) [plumbing service contract].

An example:
There is a department of motor vehicles.
They provide a queue each (for instance) for tags, licenses, registration.
A customer has a service of customized tag.
The customer will choose the tag queue and the appropriate person/agent can handle it.
The agent notices the service and applies procedures based upon the SLA.
Another customer has a generic tag and hits the same queue. Ignoring the logistics of physically being in the same queue the same day, neither customer has any idea that another customer has a customized tag unless that service has been offered/bought/assigned to you.

From the above example, you can see there were no additional controls set up on the agent side for a customer to be handled just because they have a specific service unique to that customer.

[crythias]

This OTRS's database configuration:
A queue belongs to a group.
A Customer by default belongs to "users" group unless CustomerGroups is enabled, then the Customer is a member of the "CustomerGroupsAlwaysGroups" as well as any manually assigned groups.
Services are directly assigned to customers.
Services can be provisioned when enabled in SysConfig, and Services can have sub services.
One way of managing the services and subservices is by creating a master service as the Customer and sub services as services the Customer has bought/leased/you have provisioned for the Customer.
When you're especially particular about segregating services between customers, you can create an ACL for that customer. Something like:

Code: Select all

$Self->{TicketAcl}->{'CustomerAServices'} = 
{
                     # match properties
   Properties => {
        CustomerUser => {
            UserLogin => ['some login'],
#or instead
            UserCustomerID => ['CompanyIdentifier'],
        },
   },

   Possible => {
        Ticket => { 
              Service  => ['CustomerA::toilet', 'CustomerA::sink', 'CustomerA::tub'],
        },
   },
};