We’ve been working on a “mightier” way to manage customer information and interaction, but we’ve been struggling trying to figure out how we can build a system that does more than just feed back information that you “already know” about your customers.

We’ve come to two conclusions:

1. We need to build a system that is “smart” to help you improve your relationships, not just “track” them
2. The term CRM is too narrow in scope and delivery and carries too much negative baggage

And so, we have been working for the last few weeks on a better term to describe what ... [more]

I just got back from an intensive two-day brainstorm / working retreat with the team up near Mount Tremblant in Quebec.

It’s difficult trying to make the best use of such a short period with everyone in the same physical location - it’s only happened one other time - at the beginning of this project - and it’s unlikely to happen again.

The highlights of the meetings:

• A lot of progress was made on how we integrate the customer management, customer portal, and team collaboration modules.  We discussed where they overlap, and how we can ensure smooth transitions for all of the different roles of the people who will use the ... [more]

For reporting, we started out using XML/SWF charts. I was familiar with the library and it seemed to be easy to integrate with rails (and it was). But the type of charts Scott wanted to see weren’t possible with XML/SWF charts.

After a few days of hacking, we scrapped that charting library for amCharts (http://www.amcharts.com/)

This library works great, but you need to get comfortable with configuration. Lots of configuration options, but really easy to get working with rails. Basically you just use repond_to and write the xml needed using builder and the javascript in html.

Here is a chart that is on the dashboard ... [more]

We built a CSV import for contacts. It started out being an import specifically for outlook. Once completed, it didn’t feel right, especially when we started the Act import, which some of our clients use. Having them choose what type of import (Outlook or Act) didn’t feel right either, so rather than making imports so specific, we are going with this:

We were also able to reuse the code, and support importing CSV files for ... [more]

The Alpha version of our CRM system (codenamed “Blackbook”) was released last week and I’m really excited about this initial build.

This first build represents the skeleton of the application with the key data components.  There’s a lot of great functionality in this first build including:

• Dashboard Charts
• Company and Person management
• CSV imports (worked with 38,000 records!)
• Deal ... [more]

The next generation of software will be built by companies with vision, the ability to execute, and a vibrant, engaged, and active customer community that will drive product innovation.

The idea is pretty obvious and the execution is pretty radical.

Today software companies use a prescriptive approach to software design - the software defines how people should work (”A better way to do things!”) - and use forums, salespeople, and conferences to create a passive feedback loop with their users.

This leads to innovation being led by a small number of marketers and engineers who want to ... [more]

Our first focus was building contact management for CRM. We had the major functionality already in our Groups application. We ported that over from groups (which is in CakePHP), taking advantage of single table inheritance in rails (which CakePHP doesn’t support). This allowed for less code for contacts in Rails than we had before and made pagination much easier.

We are using Behavior to keep as much javascript out of the views as possible (lessons learned from previous apps).

For example, in the screenshot below we are using default labels “Address”, “City”, “State”, “Zip” to ... [more]

We are building the new apps in Ruby on Rails.

The decision came down to how we were going to manage templates for extranets and how we were going to manage credit card processing across the new apps.

Thanks to our friends at Shopify (... [more]

Mercury Grove uses an agile programming model called “Evolutionary Prototyping” to develop its software.

Evolutionary Prototyping uses multiple iterations of requirements gathering (captured in our AppManager) and prototype development. After each iteration, the resulting product is reviewed with the “customer”.

Our particular flavor of Evolutionary Prototyping involves scouring the Open Source community for a pre-existing app to serve as the initial prototype. If we cannot find the right “fit” for the project requirements, we start with a static prototype, using either simple wireframes or basic HTML. When developing our own products, we ... [more]