Need some advice with huge implementation

[mariano]

Hi guys,
this client of mine wants to implement OTRS and asked me for help. However they're planning certain things that look pretty complex. I will appreciate if you guys can offer a little advice:
1- they have 1200 agents who are answering emails, each one with their own Outlook and personal account. Their clients are corporations and they don't want to lose the one to one relationship so instead of one queue and several agents assigned to it, they want a queue per agent (or it seems to me that's the way to implement it). Since 1200 accounts pooling for email looks like a nightmare, I was thinking to implement several instances of OTRS (e.g. 4 instances, each one with 300 accounts) sharing a same database. Do you think is feasible? Is there another option to implement the same final output?

2- he wants a little test to see how OTRS works and want me to install an external (meaning outside their servers) version of OTRS. He has MS Exchange (2003 but migrating to 2010). However, for external access he won't grant me pop or imap access to the exchange, just rpc. I google quite a bit and couldn't find a way to connect with exchange through rpc, neither directly with OTRS nor with a tool that can transform these emails to some local email server where I can access. Do you a tool for this kind of problem or some course of action to recommend?

TIA!

[crythias]

for this implementation I'd strongly recommend buying a support contract.

[jojo]

and consultancy

[mariano]

For sure. I have already contacted OTRS inc. and I'm in the talks to enter the partnership program (it's clear that we need support although it's not clear to me right now if OTRS inc. provides consultancy services too or I should contact other people). Anyway, before any of that happens I need my client to test the application and give me the green light. If somebody can tell me if the proposed scenarios are doable or not, I will greatly appreciate it.

[crythias]

You don't need (necessarily) to poll 1200 mailboxes. You could just as easily have all those mailboxes forward as aliases to one mailbox.

Understand that OTRS will delete the email from each box you connect to.

I don't recommend that one agent per queue just because management will be a hassle.

Agents won't be using Outlook to manage tickets, either.

IMAP and POP3 both have secure/encrypted options, and if that's not an option, forwarding to a gmail account or other outside account might be for the purpose of testing.

http://demo.otrs.org/otrs/index.pl

[mariano]

Thanks a lot for your valuable input.
Although I agree with you that administering that quantity of accounts will be a problem, I cannot see how each agent will be able to answer with their own email address unless I create that amount of queues. I was thinking that coding some scripts that can process things like cvs files and update, e.g., the database (I happen to know a lot about the OTRS database schema) will be a suitable solution to easy the administration burden.

[crythias]

If you're going to be doing things out of band, I'd recommend using the API to create the queues.

I don't see why you might not be able to modify TemplatGenerator.pm to send from the Agent's email address.

The problem is that OTRS has no way to know what happens outside of OTRS. Responding to the Agent's email address won't do anything inside of OTRS unless the agent wants to use OTRS as an inbox and all emails are tickets.

That said, Ticket::DefineEmailFrom

Default value: System Address Display Name
Defines how the From field from the emails (sent from answers and email tickets) should look like.

You can add the Agent Owner's name to the From, as well as the fact that ticket correspondence from the customer will still show up in the Agent Owner's inbox according the the latter's preferences.

That's the biggest problem with all the individual emails: How is OTRS going to get the correspondence? Or, if OTRS is going to get all the correspondence, how do the agents deal with non-ticket correspondence?

[mariano]

Great points. I agree with you: users won't be able to separate clients emails from colleagues but that was their requirement and as they say: be careful what you wish for...
Regarding the API, last time I checked I was under the impression you could only use Soap Lite interface and that it was really hard to use if you don't code with Perl. I'm a python developer so I just thought that direct modification in the db was the way to go for me. Missing documentation and examples didn't help either. Did that part improve in Otrs 3 or I'm totally mistaken regarding the quality of the API?