I started this book with the intention of bringing a new side of SugarCRM to light. Since I began working
at SugarCRM, I saw the flexibility and extensibility that the application could provide. I looked back on
my previous position developing internal business applications, and saw that many of the features I
added and design issues I would wrestle with were problems that SugarCRM had already solved. The
engineering team at SugarCRM had built the application to solve this problem, yet few developers
outside of SugarCRM really knew how powerful the underlying platform was. I knew there were other
developers in this same boat, and that if I could reach them it would make their jobs much easier.
What a CRM application does or doesn’t do isn’t authoritatively defined; instead, its goal is to fill in
the gap where a company needs to solve problems in their relationships with their customers.
Sometimes this means keeping track of meetings and phone calls. Other times, this means tracking the
progress of an ongoing project. It could also mean managing support cases and product defects. Yet
sometimes an application may not completely cover this. Just as every business or organization is
unique, so must be what CRM will mean to them. Up until SugarCRM, this application space was full of
players who thought they had the CRM problem solved, and built large proprietary applications that
were expensive to implement and support and notoriously difficult to customize to meet their needs.
SugarCRM came in and changed that scene, making CRM something that is inexpensive to implement,
easier to customize, and more approachable for end-users to work with. It’s designed to be a CRM that
your users won’t hate, which is the philosophy that the founders of SugarCRM set as their paramount
goal when building it.
1