Group chat is a team focused application. We see our enterprise customers struggle and even be completely ignorant to its value and features. The common route for group chat to spread in an organization is still organically bottom up. That is often uncontrolled and chaotic.

Let’s check for your company:

• Do you have Whatsapp groups and people doing business-related messaging over this service?
• Some people active on Facebook messenger?
• Maybe even a team on Slack who doesn’t care about compliance and still manages to survive?
• Some people in IT who think that IRC or internal Jabber chat server can do the trick?
• And now you want to test HipChat? Maybe as a server deployment in your environment?

I could add other group messaging solutions like Lync, Fleep, Mattermost, Google Hangouts, etc. But even without those I am sure you can already see at least two or three of these in your company today. That alone should be sufficient for IT and Corporate Communications to deal with this issue in a project.

The threat of not deploying HipChat Server or other group chat

Here are the threats you are facing if you just wait. And I strongly believe that they will grow bigger over time. There may be some industries that can still wait a little. But the more tech savvy your workforce is, the bigger these threats already are right now:

• Different solutions - You will see your employees and teams use different software tools. Non technical teams will adopt something that spills over from their private instant messaging experience like Whatsapp or Facebook messenger. From a compliance perspective of a large enterprise, this is a nightmare as Facebook (also owner of Whatsapp) does not plan to commercialize these messengers for companies but wants to display ads. "If you do not pay, you and your data are the product." You do not need to be from Germany to find this intimidating.
• Internal fights over the right messenger - If your employees have grown to love how Whatsapp or Slack do certain things, they will think, this is 'state of the art'. They will start trying to convince other teams to adopt their solution. That is especially problematic if you see evangelists of different solutions at the same time. This is how "a complete waste of time and energy" could be defined. Evangelizing group chat per se is fine. Trying to convince someone who did not experience it for one or the other is useless.
• Adoption of certain tools - Even if your coworkers do not propagate one specific tool, they will quickly adopt the one used in their team. You will face additional efforts to explain why certain things are not offered or handled differently in the solution you want to deploy. The earlier you act, the easier the job.
• Increasing resistance to switch tools - Along with adoption comes a tendency to simply not wanting to change anything. What we do with Whatsapp works just fine for my team. Now you want me to switch to a so called 'compliant' messenger. That’s cumbersome. I just want to do my work.
• Uncontrollable storage of data - If you have some of your chats stored with Facebook, some with Slack, some on any other weird server of a smaller provider, this is a nightmare if you want to control the data. You can’t back it up. You can’t make sure that data is deleted when you want it.
• Increasing likeliness of privacy and security catastrophes - Does that need more explanation? How do you try to exclude a coworker who is the admin of a Whatsapp group, when he leaves the company and does not pass on the admin role for the group. He’ll be a lurker in the group until someone else might create a new group. All historic data will be with him. Ouch!
• No chance to centrally manage users and control rights - That is also pretty straight forward. Your IT department will want an easy way to centrally control who is an employee and who is not and who can access which system. This is usually done through a central user repository like LDAP or a Microsoft-based Active Directory. Technically it is possible to connect such a user directory with multiple systems. But no one wants that in reality.
• High fees for commercial licenses - If you run on multiple solutions you will end up paying extra for users who work in multiple systems and you also miss out on volume discounts that all vendors offer.
• Very limited integration with other tools - Group chat is increasingly becoming the operating system for daily communication in technical teams. It is not unlikely that business teams will follow. For a good experience, the integration of other services is crucial. Popular Atlassian tools like Confluence and JIRA integrate with nearly every group chat. But as soon as you begin to integrate your own legacy systems or do customizations, you’ll add another layer of costs and complexity if you have to do it for multiple systems.
• @mentions will not be effective - If you have multiple systems, you’ll have a limited possibility to involve all employees in a real time discussion (e.g. with @mentions). The main problem is that everyone will be using another system and thus will not react to every mention or ping in any system.

Why you should set up a group chat project now

• The issues mentioned above will only get bigger.
• Others do it. You can exchange with and learn from them.
• Increase productivity of your workforce.
• Make communication a competitive advantage for your teams.
• Roll it out fully compliant with all internal policies. Kill the uncontrollable SaaS alternatives.
• Easy going. There is little resistance right now. If people have been accustomed to another solution with their team, they can put high efforts in sustaining their current solution. The worst I have heard so far is that Slack is "simply cool". There was nothing more to retrieve as argument. Was it UX? Was it an excuse for not switching? I never found out.

Why HipChat Server?

• Behind the firewall deployment. - Today an on-premise installation is still a must for almost all companies. Especially large enterprises will not want to compromise here. And HipChat Server allows them not to have to give in for an SaaS solution here.
• Awesome integration with Atlassian software - If you heavily rely on JIRA, Confluence or Bitbucket, you will find HipChat integration best, deepest and very seamlessly.
• Affordable pricing - If you plan a full scale deployment for all employees, the alternatives often cost multiples.

This is how you deploy HipChat Server

Let’s assume you wanted to deploy HipChat server. This is how we usually do it:

1. Prototype - We install a fast HipChat Server instance in our environment to start your prototype. Doing that with hipchat.com as host is an alternative.
2. Installation - Installing HipChat Server on one of your servers.
3. Security and Availability - Making sure that it is both publicly available and secure.
4. User Management - Sync users with your LDAP or Active Directory
5. Switch beta users over - Add new account with HipChat server credentials on employees clients (beta users).
6. Rollout - Start rolling out HipChat clients on desktops and mobile devices (automated, assisted or self-organized, or a combination)
7. Training and Adoption - Make sure that people understand use cases and benefits of using HipChat and try it out.

A HipChat Server project in a large enterprise can be complex and challenging. Contact us and we will help you from the very start until the adoption process during your rollout. We’re also open for consulting gigs within such projects.

Additional Information

Will Fleep Beat HipChat and Slack?
Comparison of HipChat, Slack, Jabber, XMPP, Lync, Skype for Business, Whatsapp and other group chat solutions
//SEIBERT/MEDIA is official Atlassian Training Partner