Here at Member.buzz, we use Atlassian JIRA to track our features, bugs, and incoming requests from users through our Support Site. So when it came to choosing a CRM, we wanted to find one that integrated nicely with the rest of our infrastructure.

Our first thought was to try out some of the existing JIRA CRM plugins. Here are the ones we tried out:

Although there were definitely some interesting features among these options, there was nothing substantial enough to make us want to choose a specific one. We wanted something simple, yet well-integrated into what we already had setup.

So we decided to build it using Native JIRA.

Our first step was to create all of the Issue types:

Issue

Description


Customer

A group or organization that is using our product or may eventually do so. Clients will normally be associated with several Contacts and Interactions.


Contact

An individual, usually associated with a Client or Investor, who can be contacted. Contacts will normally be associated with several Interactions and one or more Clients or Investors.


Investor

An investor is an entity that has already or may eventually invest in us. Investors will normally be associated with several Contacts and Interactions.

 

Bucket

Groups Customers (Networks and Sites), Investors and Stakeholders into logical groups. These groups can be used to differentiate between Pipelines.


Interaction

The CRM equivalent of a Feature. This can be either a Meeting, Call or Email and will normally be associated with a group of Contacts.

Associating CRM Issues

At its core, a CRM is focused on tracking the interactions that your team has with other people.


As you can see, an Interaction can be associated with any Contact, Client or Investor.

To show how it works, we can take an example. Take the following Client (a real Member.buzz customer). This page contains all of the basic information:


If we scroll to the bottom of the page, you will see several linked issues:

The association between the Client and Contacts is automatically created by including the Contact's ID in the Description (thanks to the JIRA AutoLink Plugin). The Interactions listed here represent a meeting that took place with the Client. To separate the different types of issues, checkout the Issue Matrix plugin.


Ready to learn how you can push your support infrastructure to the next level? Click here to read about using Atlanssian and RefinedWiki to Create an Awesome Support experience! 

Comments

To add a comment, please login or register.

Related

Setup Point-to-Site VPN with Ubiquiti EdgeRouter
Learn how to setup a VPN with your Ubiquiti EdgeRouter.
Using a Lenovo P51 Laptop with an Airplane Power Supply
The Lenovo P51 Laptop comes with a huge 170 watt Power Supply. However, airplane power supplies provide a maximum of somewhere between 75-100 watts. If you plugin a power supply requiring more watts, the circuit breaker will short out and the power will stop flowing.
C-Level Security: When your team uses military analogies, are they using the wrong narrative?
For years, I have bristled when people would use medieval military descriptions in an attempt to convey concepts within the Network Security business. Bastions, Firewalls, Moats, Drawbridges, Countermeasures; all of these descriptions give way to a more accurate and detailed explanation of what was really taking place.
What to Say to the C-Level, get your security project funded today!
In near every business adding costs to Information Systems will be seen, by the people running the business, as a cost first, benefit second. Remarkably this still holds true despite a constant pulse of security events hitting the C-Level desks. So let's, as security professionals, develop an understanding of the C-Suite and the C-Levels as to their priorities.