We are an IT firm, providing outsourced IT solutions for our clients.
We have deployed a local server, and servers at several of our larger clients. The client servers all connect to our internal server, and we have groups named for each client with their employees in them. The clients have their local users, as well as groups for users at any remote offices they may have (as such, we have deployed the server to all client sites for those clients we have done this for).
We found options like MSN Messenger, Yahoo Messenger, and other public solutions weren’‘t reasonable solutions. Users spent far too much time chatting with friends and family at work. It’‘s very difficult to control the impact on productivity of public messaging solutions. As a result, we have blocked all public messaging solutions at the firewall with advanced packet filtering (port blocking alone isn’‘t enough - most public solutions will just keep changing ports until they eventually end up on port 80, and then you’'re stuck). We also had to block the web-based clients for the public solutions (meebo, for example, and several others). We have blocked XMPP traffic from internal clients to the outside world, too, to stop users from using public Jabber servers. XMPP traffic to/from the Internet is allowed to/from the internal server only. We have also used the firewalls to control connectivity in server to server situations via static IPs, further protecting the network. In many cases, client servers communicate with remote sites via VPNs for even greater security. In short, we have things locked down very tightly to avoid user producitivy problems.
Granted, this doesn’‘t stop staff from chatting with other staff about non-work related issues, but that happens anyway via e-mail or the phone, or worse - people get up from their desk and socialize in person if they can. You can’‘t stop all producivity waste in all situations - you just hope the solution in question does more good than bad. In the case of internal corporate IM, clients have found tremendous productivity gains and few losses, so it’'s been very well received.
With a local IM server, however, it’‘s easy to control who can connect, who has accounts, etc. We have denied the ability for users to set up their own accounts, so we (or the client’‘s local IT staff) have absolute control over the server’'s security.
At this time, we have several clients with remote offices spread across Canada and the US, and they’‘re finding the ability to quickly communicate with users anywhere in the organization without having to resort to the phone or slower e-mail communication has increased the speed and efficiency of their companies. The ability for them to see who is at their desk through the use of online/away status helps them locate people quickly, too (rather than e-mailing and waiting, or calling and if they’‘re not at their desk, having them paged - those methods are slow). Also, most of these clients have users that travel between offices. Users don’‘t need to know where a person is physically - they can just IM them, and the message will find it’‘s way to the user wherever they’'re logged in.
We’'re currently in the process of deploying mobile clients on devices such as Blackberries and Microsoft Mobile smart phones. At the moment, we have a few of the upper level executives and several sales people of about 5 firms using the feature as a test. So far, they love the ability to reach staff from anywhere, anytime and vise versa.
At the moment, we have been using PSI as the desktop client, and IM+ for the mobile client (too bad there’‘s no version of PSI available for mobile clients. IM+ isn’‘t a free option, but it works). PSI has been easy to install, and we’‘ve found it works well with roaming profiles on Windows systems (PSI’‘s configuration file lives in the user’'s Documents and Settings/Username folder, so it travels with the profile properly). PSI has been extremely stable for us so far, as has Wildfire (especially the new 1.5.0 release - server to server works flawlessly now - we used to have to restart servers now and then to fix connectivity problems with server to server in the previous release).
One quick note about Windows Mobile based users - if the device goes to sleep (they all do, to save battery life), the IM client will disconnect and users will not receive messages from remote users. Blackberries don’‘t have that problem. Something to keep in mind. Hopefully a client will come along that will either do some kind of keep-alive scenario to keep the connection open. If not, the talk about a SMS message being sent to offline users in a future version of Wildfire may help relax the problem (there is a small email on away plugin developed by a community user that can send e-mails to an SMS account, but it’'s an “all users or no users on a given server” solution at this time).
If you end up deploying mobile clients with IM+, or using different desktop clients, make sure you set the resource names to match on all clients if you want users to be forced to sign out of their desktop clients when they connect from a different client. We ran into that early on, and it provided for some fun for the users until we noticed the problem (a user can be signed in more than once with different resource names - it was confusing for users!)
In total, we probably have over 600 people using Wildfire at various sites, all of them connecting between sites and/or back to our local server. We’‘re quite satisfied with the solution - especially in terms of cost (Microsoft Live Communication Server is exremely expensive, if all you’‘re going to use are the IM capabilities). We’‘re so impressed that we’‘re looking at some of Jive Software’'s other solutions, such as the knowledge base and forum products.
It’‘s free to try it, so why not? If a small roll out to a group of users that are most likely to benefit from an IM solution is successful, go all the way with it. When trying to get a new idea approved, it’‘s import to target users that are a mix of technology savy users, management users, and users at a remote site (if applicable) if possible. That way, you have some people who will catch on quickly and say good things about the solution (as well as help out other people who aren’'t so quick to pick up on new concepts), some people who have pull in the organization to get a full roll out authorized, and some people who will benefit greatly from faster communication with other staff (who will also say good things). Make sure the test subjects get plenty of help and some instruction on how to use the system (a web page with basic help on the corporate intranet website is a good idea - or an e-mail with the same type of information - or both).