Deployment Inquiry

Hello Everyone!

First off, excellent list! I’ve been a lurker on here for about a year
now and some great information and discussions abound, thank-you all!

I have a question regarding deploying RT. Currently we use individual
queues for our product line, internal support, and interdept. requests.
This keeps the queue list to a manageable amount. I was curious if
anyone has deployed with a queue per customer instead of product,
service, etc. If so, does this render your queue list a bear to manage,
or has it been a successful deployment type for you? Tips and/or
suggestions, pitfalls/gotchas?

Thanx for any and all feedback.

RT, thanx for your product, it is really great!

Warm regards,

Todd Rittinger
Technical Support Manager
t. 519-826-5222 ext. 237
f. 519-826-5228
todd.rittinger@netsweeper.com

Corporate Head Office
104 Dawson Road
Guelph, Ontario
N1H 1A7

My take on this is, why have a queue per customer when you can have a
group per customer …
After all customers are only a group of requesters …
In the set up I have here we I Queues to represent departments and hence
escalations is as simple as changing ticket queue etc …

Regards;
Roy

Todd Rittinger wrote:

Hello Everyone!

Hello :slight_smile:

I have a question regarding deploying RT. Currently we use individual
queues for our product line, internal support, and interdept.
requests.
This keeps the queue list to a manageable amount. I was curious if
anyone has deployed with a queue per customer instead of product,
service, etc. If so, does this render your queue list a bear to
manage,
or has it been a successful deployment type for you? Tips and/or
suggestions, pitfalls/gotchas?

My org uses a queue per customer and it’s been working out quite well
for us. Management of the queue list is not much of a burden, it only
takes a few mins to add a new one. We rarely need to remove a queue.
I guess the amount of customers you have (and how much customer churn)
will dictate how well it could work for you.

Regards
Huw

s2s company email disclaimer : http://www.s2s.ltd.uk/datasheets/email_disclaimer.pdf
s2s company registration number : 3952958
s2s VAT registration number : GB763132055
Business premises : Ground Floor, Overline House, Crawley, West Sussex, RH10 1JA
Registered address : Heathcote, Kings Road, Ilkley, West Yorkshire, LS29 9AS
Place of registration : England

This is the method we use. As an organization with an ever growing customer
roster it makes more sense for us to keep our queues limited to internal
departments. We have a custom field which we use to determine the customer to
which a ticket “belongs”.

Mathew

Roy El-Hames wrote:

My take on this is, why have a queue per customer when you can have a
group per customer …
After all customers are only a group of requesters …
In the set up I have here we I Queues to represent departments and hence
escalations is as simple as changing ticket queue etc …

Regards;
Roy

Todd Rittinger wrote:

Hello Everyone!

First off, excellent list! I’ve been a lurker on here for about a year
now and some great information and discussions abound, thank-you all!

I have a question regarding deploying RT. Currently we use individual
queues for our product line, internal support, and interdept. requests.
This keeps the queue list to a manageable amount. I was curious if
anyone has deployed with a queue per customer instead of product,
service, etc. If so, does this render your queue list a bear to manage,
or has it been a successful deployment type for you? Tips and/or
suggestions, pitfalls/gotchas?

Thanx for any and all feedback.

RT, thanx for your product, it is really great!


The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Keep up with me and what I’m up to: http://theillien.blogspot.com

Todd,

If you handle each customer/company as an entity with it's own list of 

Privileged Requestors (preferably in a group), then it wouldn’t be any
different than an RT session that handles requests from different
organizations/departments within a company/session. We have different
organizations/departments that are defined/catagorized by a Custom
Field. When they send in a ticket request (via self service), they send
it to the email address we gave them for the queue we set up for their
requests. That queue has 1 group defined and privileged as requestors
(they are the users from that department/organization allowed to
“create”, “reply”, “see” tickets) and 1 group defined and privileged as
support (only they can “own” and “modify” tickets in that queue). We
also pick 1 person from the “support” group to act as “queue manager” by
making them the “AdminCc”. That’s what works for us in both managing the
requests, but in getting good administrative reporting.

Kenn
LBNLOn 2/28/2008 7:13 AM, Todd Rittinger wrote:

Hello Everyone!

First off, excellent list! I’ve been a lurker on here for about a year
now and some great information and discussions abound, thank-you all!

I have a question regarding deploying RT. Currently we use individual
queues for our product line, internal support, and interdept. requests.
This keeps the queue list to a manageable amount. I was curious if
anyone has deployed with a queue per customer instead of product,
service, etc. If so, does this render your queue list a bear to manage,
or has it been a successful deployment type for you? Tips and/or
suggestions, pitfalls/gotchas?

Thanx for any and all feedback.

RT, thanx for your product, it is really great!