Customer Group as Generic Agent filter condition
Greetings to all, this is my first post in this group, I tried to find an answer to my problem googling around but without any luck. I need a bit of help with OTRS 3.2.1 in creating a Generic Agent script for my company, basically this is what i need: My company has a number of queues based on various products, but every customer is mapped to a group which refers to an Agent as responsible (Key Account for customer). When a ticket is opened on OTRS by customer sending emails to the system, i want to check who is the customer, look for its group and then automatically assign the ticket to the account manager for the group as responsible. I don't know if i made myself clear :/ I know i can map each and every customer to a Responsible using Generic Agent, but here we are speaking of thousands of them... it would take ages to create all filters... Using the Customer Group function would be a nice help, but there is no such possibility in Web Interface and i don't know the exact variable name (and if it's usable) for the GenericAgent.pm script Thanks in advance for any help Feel free to point me in another direction if i'm going on a bad road! :) -- *Lynx International Srl* *Stefano Finetti* *Senior System Consultant* *Axed Group* Via Pier Luigi Nervi e/3 - Torre 6 - 04100 Latina Skype: *ssfinetti* * * -- This e-mail and any files transmitted contain documentation which is highly confidential and intended solely for the use of the individual or entity to whom they are addressed. All written data and other information in the documentation is and shall remain the property of the disclosing party. If you are not the intended recipient you are hereby formally notified that any disclosure, dissemination, forwarding, storing, copying or use of any of the information is strictly prohibited and will be legally pursued. If you received this in error, please contact the sender and destroy the documentation including deletion of the same from any computer. Thank you.
Probably easier to give customer a dedicated email for responsible agent.
You'd set up an aliased email to your otrs mail fetch box and dispatch by
to.
Customer groups are permissions and since it is possible that a customer
can be members of multiple groups, your suggested path is not optimal. On
the customer side, I'd extend the customer table schema and the Config.pm
Map to hold an attribute related to account manager.
Then again, if a customer owns multiple of your products, what is your
plan?
On Feb 13, 2013 5:05 AM, "Finetti, Stefano"
Greetings to all,
this is my first post in this group, I tried to find an answer to my problem googling around but without any luck.
I need a bit of help with OTRS 3.2.1 in creating a Generic Agent script for my company, basically this is what i need:
My company has a number of queues based on various products, but every customer is mapped to a group which refers to an Agent as responsible (Key Account for customer).
When a ticket is opened on OTRS by customer sending emails to the system, i want to check who is the customer, look for its group and then automatically assign the ticket to the account manager for the group as responsible.
I don't know if i made myself clear :/
I know i can map each and every customer to a Responsible using Generic Agent, but here we are speaking of thousands of them... it would take ages to create all filters... Using the Customer Group function would be a nice help, but there is no such possibility in Web Interface and i don't know the exact variable name (and if it's usable) for the GenericAgent.pm script
Thanks in advance for any help Feel free to point me in another direction if i'm going on a bad road! :) -- *Lynx International Srl* *Stefano Finetti* *Senior System Consultant*
*Axed Group* Via Pier Luigi Nervi e/3 - Torre 6 - 04100 Latina Skype: *ssfinetti* * *
This e-mail and any files transmitted contain documentation which is highly confidential and intended solely for the use of the individual or entity to whom they are addressed. All written data and other information in the documentation is and shall remain the property of the disclosing party. If you are not the intended recipient you are hereby formally notified that any disclosure, dissemination, forwarding, storing, copying or use of any of the information is strictly prohibited and will be legally pursued. If you received this in error, please contact the sender and destroy the documentation including deletion of the same from any computer. Thank you. --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
Il giorno mercoledì 13 febbraio 2013 13:18:53 UTC+1, Gerald Young ha scritto:
Probably easier to give customer a dedicated email for responsible agent. You'd set up an aliased email to your otrs mail fetch box and dispatch by to.
Unfortunately this is not an option. My company has a dedicated email address for support tickets and I don't think they'll want to change this.
Customer groups are permissions and since it is possible that a customer can be members of multiple groups, your suggested path is not optimal. On the customer side, I'd extend the customer table schema and the Config.pm Map to hold an attribute related to account manager.
Actually on my otrs installation a customer can't be part of more than one group, 'cause the only way customers open their tickets is by mail or by phone. They have no login to the customer.pl portal. Groups are used only for agents and queues and are product related. It's, however, very interesting the option about extending the customer table and customer Map. Do you think I could be able to filter using that attribute in GenericAgent?
Then again, if a customer owns multiple of your products, what is your plan?
Well i know it sounds weird, but this isn't a real problem. Customers are surely linked to more than one product, but when they open a ticket, for any of the products they use, the ticket will have as "responsible" the "Key Account", while the "operator" will be the person in charge to solve their problem. I could create a group, for example "Stefanos_Customers" and link all my customers to that group. If I could use this group as a filter in a GenericAgent script, it would solve my need of automatic assegnation of the ticket (carelessly of the queue) to the responsible person. Thanks Stefano -- This e-mail and any files transmitted contain documentation which is highly confidential and intended solely for the use of the individual or entity to whom they are addressed. All written data and other information in the documentation is and shall remain the property of the disclosing party. If you are not the intended recipient you are hereby formally notified that any disclosure, dissemination, forwarding, storing, copying or use of any of the information is strictly prohibited and will be legally pursued. If you received this in error, please contact the sender and destroy the documentation including deletion of the same from any computer. Thank you.
Il giorno mercoledì 13 febbraio 2013 11:04:34 UTC+1, Stefano Finetti ha scritto: [snip] In the end, i solved my problem following some of Gerald's precious advices. I removed CustomerGroups, because i really didn't need them. I've added a field into customer_company table, and created a new GenericAgent perl module that looks for the name of the responsible into that field and set the new Ticket Responsible into the ticket. It was easier than i thought, i was simply looking in the wrong direction! Thanks again to Gerald for putting me in the right direction! -- This e-mail and any files transmitted contain documentation which is highly confidential and intended solely for the use of the individual or entity to whom they are addressed. All written data and other information in the documentation is and shall remain the property of the disclosing party. If you are not the intended recipient you are hereby formally notified that any disclosure, dissemination, forwarding, storing, copying or use of any of the information is strictly prohibited and will be legally pursued. If you received this in error, please contact the sender and destroy the documentation including deletion of the same from any computer. Thank you.
participants (3)
-
Finetti, Stefano -
Gerald Young -
Stefano Finetti