For my particular set up, I just found out we won't even be providing access for customers to log into the web server. We will basically use it to log calls that the customers phone into our Ops Center. I want to have a way when starting the ticket to choose the customer (which I notice that already works quite nicely) and then have the ticket be sure to capture that this ticket is from Company X or Company Y based on the customer's account info in the DB. This is why my original question was how do I tie customers to companies?
Gerald, if you don't recommend using the CustomerID field in the Add New Customer screen as a COMPANY NAME that also is already entered as a Company in my OTRS setup, how do you suggest I use the CustomerID field and how do you suggest I associate a customer (human) to a company? I just read the thread you pointed out. It seems that you agree that "IBM" can be used for CustomerID in the Add New Customer screen. If I am not at all worried about customers from Company X seeing tickets from Company Y (because none of them will have web access anyways), does this seem like a good route to go? Thanks again. You've been a huge help these past few days. Daniel From: [email protected] [mailto:[email protected]] On Behalf Of Gerald Young Sent: Tuesday, January 25, 2011 12:23 PM To: User questions and discussions about OTRS. Subject: Re: [otrs] associate customer to company? Marco, yes, I agree with you. :) I don't know if it applies to the original request (associate customers with companies), but it does allow reducing queues for customers, potentially using the groups as "companies". As I think about it, in 3.0, one may be able to send a Notification (Event) to an entire group, and as far as I can tell, this is the only specific way OTRS can send any correspondence to an entire customer company, if all the customers of a company are members of that group. On Tue, Jan 25, 2011 at 10:03 AM, Marco Vannini <[email protected]<mailto:[email protected]>> wrote: indeed every installation and usage are to be evalueted... as usual, but, just to start, one has to understand the usage and feature that the tools offers and then plasm it at his organization/flow/needs On Tue, Jan 25, 2011 at 3:54 PM, Gerald Young <[email protected]<mailto:[email protected]>> wrote: I don't really want to suggest that because of the reasons stated in the link I provided in the forums. (Briefly: customers of the same company may NOT need to know what other customers have submitted (the Company Tickets tab can give a customer that access for tickets that have the same customer_id (company) as the customer). It is not possible for you to arrange customer<->groups and manage different group for different queue ? This is another conf method, do you agree ? But a department head/manager may very well need to see tickets submitted for his company (see customer_ids). CONFIDENTIALITY NOTICE: The contents of this email are confidential and for the exclusive use of the intended recipient. If you receive this email in error, please delete it from your system immediately and notify us either by email, telephone or fax. You should not copy, forward, or otherwise disclose the content of the email.
--------------------------------------------------------------------- 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
