Scalability problem, OTRS 2.4.9

[ande0ne]

Hi Everyone,

First off, I'm quite new to OTRS and therefor some of the following questions might have obvious answers to most of you , i beg a pardon for that..

We're using OTRS as a ticket-based support system for our customers, we have alot of customers using the OTRS and we're satisfied with it's functionalities. However we're starting to experience some scalability problems with our current setup. First off, let med describe our current setup:

- We have about 30 Queues in OTRS, each queue is linked to a larger customer, except 2-3 queues which are linked to smaller customers where several customers can contact the same address, and therefor the tickets are handled from the same address.
- Each queue has a unique e-mail address linked to it.
- There are about 100 Agents handling tickets in the system, most of these users aren't frequent users. They check the system once or twice per day.
- Each agent is mapped to one or several queues.

This setup has worked great so far however we don't think it's a viable solution when the number of customers linked to OTRS is growing fast. We haven't upgraded our OTRS client since version 2.4.9, so i don't know if there is any new functionality in the latest version of OTRS which we can't use now. The problems we're facing regarding scalability are:

- Number of queues are getting out of hand, hard to monitor and administrate.
- Agents have to use the "My queues" function because they can't navigate between alot of different queues in the interface. This makes it hard to priortize work according to SLA's etc
- To tag a ticket with a Customer ID the sender of the ticket has to be registered in the system. Takes time to constantly update list of people approved to send in tickets.

We've looked into some options in order to make our setup more efficient but haven't come up with a solution just yet, following are some of the options we've looked into:
- Tickets get tagged with a customer ID depending on the e-mail address that the ticket was sent to.
- Alternatively the domain of senders e-mail address decides the Customer ID on the ticket, e.g: all tickets from domain "@companyA.com" gets tagged with Customer ID "Company A".

Our vision is that we somehow can link a group of Agents to one queue where tickets from 4-5 customers are placed (not just linking several e-mail addresses linked to one queue), that way we can manage our OTRS structure like our organizational structure.

My question to you guys is:
- if you have any experience of these "problems"?
- if you have any recommendations to how we could organize our setup better?
- if you have any hints on functionality that could help us solve our problems?

Thanks in advance!

Best regards,
Anders Levin

[crythias]

we don't think it's a viable solution when the number of customers linked to OTRS is growing fast

That's why you shouldn't be using Customer Based Queues. Queues should be what the agents can do, not who needs help.

Tickets get tagged with a customer ID depending on the e-mail address that the ticket was sent to.

How about the tickets get tagged with a customer ID depending on the email address that ticket was sent from?

Takes time to constantly update list of people approved to send in tickets.

This is the peril of what you've created, but if this takes more time than everything else you've devised, ...
Most of the time, this is either to be handled in a batch or as it happens. If this "happens" too frequently, then you might want to ask your company-clients for a approved sender list, then batch create the users.

Our vision is that we somehow can link a group of Agents to one queue where tickets from 4-5 customers are placed

That's what it's supposed to do ... the queue should be "Product Support", for instance.

[ande0ne]

Thank you for the quick reply Crythias!

I've got some counterquestions to your suggestions:

we don't think it's a viable solution when the number of customers linked to OTRS is growing fast

[That's why you shouldn't be using Customer Based Queues. Queues should be what the agents can do, not who needs help.

Agent based queues seems to be the way to go then... However our customers often want a simple support address like "support.companyA@OurCompany.com", "support.companyB@OurCompany.com". If we were to link these addresses to general queues like "support.product@OurCompany.com" then the answer would be sent from the general address, thus making it a problem.. Is there any way to get around this issues? If there is, I think Agent based queues might work for us.

Tickets get tagged with a customer ID depending on the e-mail address that the ticket was sent to.

[How about the tickets get tagged with a customer ID depending on the email address that ticket was sent from?

Can tickets only be tagged depending on the email address that the ticket was sent from? There is no way to tag a ticket depending on the e-mail address it's sent to?

Takes time to constantly update list of people approved to send in tickets.

[This is the peril of what you've created, but if this takes more time than everything else you've devised, ...
Most of the time, this is either to be handled in a batch or as it happens. If this "happens" too frequently, then you might want to ask your company-clients for a approved sender list, then batch create the users.

I think our main issue here is that we often communicate with vendors and customers to our customer, making it almost impossile to import a large amount of users as a batch. Our customers rarely have a good idea of the people allowed to contact our support. Some corporations are large as well with alot of changes within their organisation, making this a daily routine.. Almost a constant routine..

Our vision is that we somehow can link a group of Agents to one queue where tickets from 4-5 customers are placed

That's what it's supposed to do ... the queue should be "Product Support", for instance.

I agree, if the issues described above could be solved. This would be great!

Regards,
Anders Levin

[crythias]

the answer would be sent from the general address, thus making it a problem

Why is it a problem? You're going to have a problem anyway in the conversion to agent based queues. That is to say, you're going to have to tell your customers that you're using a new addressing scheme, whatever it is. I don't know why support.companyA is simpler than support@ourcompany, though.

There is no way to tag a ticket depending on the e-mail address it's sent to?

What tagging do you want? The CustomerID is the customer/company. The Queue is the hat in which the ticket sits, and the Owner is the agent who has the ticket.

we often communicate with vendors and customers to our customer, making it almost impossile to import a large amount of users as a batch.

Our customers rarely have a good idea of the people allowed to contact our support. Some corporations are large as well with alot of changes within their organisation, making this a daily routine.. Almost a constant routine..

While I empathize with your plight, I have to do something similar, but when it comes down to it, I need to make sure that the people who submit tickets are my customers.