Screenshot of our Highrise account showing 3600 contacts
This is kind of a long-term review of the customer relationship management tool Highrise, made by 37signals. I was leading the team introducing the system into IAESTE Austria's IT infrastructure between 2011 and early 2012. I learned a lot during that project and I want to share some of it here.
This is not an introduction or a quick how-to, but you can find many like those on Google.
Pre-Story
IAESTE is a global organisation organizing internships for students of engineering and natural sciences. IAESTE Austria is the national incarnation of it in Austria, which is run entirely by students and in addition to the internship exchange program it also runs several career fairs and other events.
IAESTE Austria in 2011 had about 150 to 200 student members and contact with 1500 people at partner organizations (companies, universities) in total. Managing and documenting communication with partners was difficult as there was no centralized CRM system. Instead, each of the six local committees had its own system (sometimes more than one) - the systems were not linked or coordinated. Of course this led to problems - when there was a large project, many contacts were contacted multiple times, people in other branches of IAESTE Austria did not know what was talked about, etc.
Back in 2009 already, it was decided to start looking for a solution. A requirements analysis was done involving many parties. Some of the requirements we discovered were:
- storing of conact information of companies and associated persons
- storing of notes about each communication with a person or a company
- grouping partners into many different dimensions (e.g. by location, by what projects they are interested in, by responsible person)
- many different flavors of reporting and status overviews
- permissions system
- import of all our data
- LDAP authentication
- etc.
There were a lot of CRM solutions around and deciding which one to use was not easy. Most of the systems had no possiblity to have both companies and people within one system, which was important to us. Also, many systems did not provide us with a possiblity to group partners the way we wanted. Ease of use was a major concern as our members were volunteers and they would simply not use a system they didn't like. Also pricing was an issue - as a student organization we did not have access to a lot of money; however, we had a lot of people; this meant to basically exclude any system that had a per-user pricing scheme.
After reviewing dozens of systems it was decided in 2010 to try SugarCRM, a very complex open source solution with professional support options. A problem of SugarCRM was its complexity. Initial tests showed that our members were very confused about all the features. Also, there were several problems in the introduction phase that we did not find any solutions to. We even contacted a small company providing support but they couldn't help us. I am sure that the system would have worked if we had invested in more professional support and if we had the ability to send all our users on a full-day-training of SugarCRM, but that was no good solution for us. We created a manual explaining what the meaning of different features was in our context, but that made it even more confusing for people. After a lot of frustration we decided to go back to the beginning…
We had seen that the most complex and feature-rich system did not solve our problems but made them worse, therefore we thought about our requirements again. We realized that many of the points on our requirements list could be achieved through "tagging" instead of complex modification of the database fields. Also, we decided to give up looking for solutions that would support our LDAP authentication and we also reduced our requirements in the area of reporting. Now, we just wanted something our users would like, so that we would collect as much useful data as possible. We decided to try out the easiest solution we could find - Highrise.
Highrise did not provide all the features, but it was simple to use, motivating our members to use it. Also, it looked quite nice adding further motivation to work with it. Tagging worked very well and the relationships between companies and their employees was visualized quite well. Also, 37signals provides a nice API which allowed us to import all our data within a few days. The API would also enable us to create complex reports if we really required them.
Introduction Phase
How to introduce a new system into a large organization spread over a small country? We soon realized that just creating one account per person and opening it all up for them wouldn't work with such a large user base. We are a student organization, so sending everyone to a seminar was not possible and sending the experienced experts to all the local committees to show Highrise around also would have been too much work.
We decided to go to the opinion leaders over the summer break 2011 and introduce the system in autumn. We identified several people who were very engaged in the organization and very social to be opinion leaders. We showed them how to use Highrise and asked what their opinions were. We received quite positive feedback and some new ideas on how to do things. The plan worked quite well and the opinion leaders told others about the system, who then requested accounts for themselves.
However, at this point we were still a bit worried. What would happen if everyone, without any training, would suddenly start using the system? Would talking to one another be enough training? Would they delete each other's entries? Would they fill it with confusing, useless entries? Would they create duplicate entries? Also, we could not rely on the opinion leaders to tell everyone precisely how to use the system.
Many people in our target group were not IT people - some were even sceptical about online platforms. There would for sure be many users who wouldn't find their way themselves.
We decided to create a guide and some simple rules on how to use the system. The most important rules we wanted to communicate were:
- "don't delete stuff" - we were very concerned about people deleting stuff on purpose or by accident
- "use tags" - we felt that Highrise isn't perfect for managing a large number of contacts if they were not tagged properly. So our manual included a few examples on what "good tags" and "useless tags" were.
- "merge duplicate entries" - this was a major concern as we had imported entries from several different old databases and expected many duplicates.
- "write meaningful notes after talking to someone"
- "store as much communication as possible"
Of course, people do not like reading manuals, so we asked ourselves how to make sure that every new Highrise user would know these rules (or, at least, some of them). We set up an account at ProProfs - a website for teachers to set up online tests. If someone wanted to get one of the Highrise accounts, they would have to do the test first and get at least 70% of the points. We designed the questions to be not too difficult and to display the correct answers at the end of the test - so anyone could figure out the correct answers without reading our howto after a few tries, but that was good enough for us - after all, we didn't want the first experience with our new system to be frustrating for users.
I believe that the test also had a secondary effect that we did not anticipate in the beginning. Our organisation is usually very open and trainings and tests are a real exception. The test showed users that Highrise was not some toy we bought, but that it was something serious, people who finished the test with a good grade felt good about themselves and well prepared.
We also had some events in early autumn where we were able to do presentations of the Highrise system and do the online tests right away. This was important to push the user number in the introductory phase.
So more and more people were interested in using Highrise - or were forced by their group leaders to do so. They did the online test, sent us a screenshot and the IT team would then create an account for them. We aimed to activate accounts within 24 hours after receiving the positive examiniation screenshot. As we were three people on the project at that time, this worked quite well.
Between September and December 2011 the number of our users grew from about a dozen to around 100.
Quality of data collection
In the early months, my team and I still observed closely what people were doing. When we noticed that someone was doing something wrong (i.e. use the "wrong" tags, create duplicates, write too short notes), we would contact them and tell them how to do better. In general, data collection went quite well.
We believe that our testing system reduced the problems a great deal, however there were still some low-quality entries. We regularly sent out messages to everyone in the organization reminding them of important rules to follow and showed them best-practice examples, this certainly helped.
Our IT team is now working on other projects and we are not monitoring entries as we used to in the beginning. Today, almost 10 months after broad introduction, the quality of notes entered is very high, however the downside is that several users don't use the system at all anymore after they found out that they have to think hard about meaningful entries.
We think that it is really up to project managers to push their supporers to use the system properly. If the project manager does not tell his team members to use it, they usually won't. The task of the IT team for the future will be to motivate the project managers in order to have the whole project team use the tool and collect data.
In the past year, some project leaders were not too motivated to use Highrise and now their project's communication isn't well documented. However, we believe that this would have happened with any system, maybe even much worse. After all, we think that it is not possible to make CRM any easier than Highrise.
Forcing our voluntary users to use something is not easy and I believe that in many actual companies it won't be much different - if someone doesn't want to use it, they won't - if they are forced to use it against their will, they will not provide a lot of meaningful data.
It all comes down to the formula: The more people use it, the better it gets. The better it gets, the more people will use it. Therefore, we hope that the problem will solve itself by having some motivated people making the system indispensable for everyday use.
Our 5-point micro-manual
Technical Integration
User base: Unfortunately, Highrise did not provide LDAP or any other authentication integration that would relieve you of creating accounts manually. However, we found that this was not too bad as it enabled us to selectively give out accounts to the people who really needed them instead of opening up the system to all our users simultaneously.
Import: The API and the CSV-import feature allowed us to quickly write scripts to upload all our existing data from legacy systems. The API sometimes had timeout problems, but this could be solved by "paging" e.g. only uploading 100 notes at a time.
Data collection: We were able to use the API and the "sending email into Highrise feature" to enable other tools to send messages to Highrise directly; e.g. if a company uses our online portal to register for participating in an event, the tool will automatically add a note to the company's highrise entry. This helps a great deal.
Lessons learned / Hints for you
If you plan to introduce a CRM (e.g. Highrise) into an equally large or even larger organisation, here a few points to consider:
- Find the best CRM for you: Highrise isn't perfect for everyone. For us it is good because of its simplicity and user interface. You might need something different.
- Talk to the opinion leaders and project managers: Show them the CRM systems you are considering. When you have chosen one system, stick with it and get managers to use it and make them show it to others.
- There will be some opposition to anything new, but that will happen with any solution you choose, don't let them change your evaluation unless they have really good arguments.
- Write a manual specific for your needs: We added rules for our organization to avoid (or at least reduce) chaos. I still feel that reminding people about best practice usage is important. This not a replacement for the built-in manual of Highrise, which provides knowledge. The manual of Highrise would tell you how to merge entries if you knew where to look. Our manual's mission was rather to tell people that merging is important and that they should think about doing it when they see duplicates.
- Consider doing tests before allowing users to use the system. This not only raises the quality of data collected, but it also makes people feel good about their achievement and makes them consider the system to be somewhat more important than other systems they didn't have to do tests for.
Getting Support
After posting this article initially I received many requests for help. Unfortunately, I am not able to support you with your Highrise integration. 37signals provides an API for working with Highrise programmatically. Also, they have a great customer support service.
Support resources
Conclusion
One year after beginning to introduce Highrise, I feel that the solution works really well and most people are happy with it. Of course, we could have tried to find something better that has better integration into our system, however the required resources would have been much greater. Everyone managing projects knows that going from 80% happiness to 90% happiness usually requires many times more resources and reaching 100% happiness is impossible.
It is good to have a team to discuss and work together on problems. I was on this project from the beginning, most of the other faces changed over time. In the beginning, the team was quite loose - just some guys who were interested. When we got stuck with SugarCRM problems, several people were too demotivated to continue the project. Highrise again was a huge debating point. Some people thought it was too simple and did not have enough features, however others saw the potential that lied in the simplicity of the system and helped me introduce it to the whole organization.
Sometimes, when you call some company, you soon realize that their CRM shows them everything about you instantly. On the other hand, when calling another company you can hear them type stuff into their computer not finding out anything about you. Highrise is not perfectly integrated into all of our infrastructure. However, the ability to store notes from other systems automatically is very helpful. After all, I believe that there are many companies and organizations out there which paid a lot of money for a custom-built CRM solution that is supposed to be fully integrated into their whole infrastructure that doesn't work as well as our cheap, easy-to-use, out-of-the-box Highrise solution.
Introducing Highrise into IAESTE Austria surely was a great project and I hope that they will continue using it long after I have left the organization. I learned a lot during the project - the most important lesson I believe was that the easiest solution, even if not perfect, is sometimes the best solution.
Disclaimer: As of writing this, I am in not affiliated with 37signals any other way than being a customer. I am not affiliated with any of the other mentioned providers of CRM systems. I did not receive any money for writing this report. This is not to be considered a recommendation to use Highrise or any other system, I am just telling about my own experiences. Your requirements might be completely different.