Salesforce.com for Wealth Managers
Andy Gluck at Financial Advisor Magazine has an interesting roundup of the customer relationship management (CRM) options for investment advisors. He touches on the two traditional industry options: Junxure and ProTracker. Next, I was expecting him to talk about some of the new web-based options that Joel Bruckenstein wrote about back in January. (I haven’t heard anything recently about Redtail, Upswing, Advisor Tools or Nation Builder.) But Andy didn’t mention them at all.
Instead, the article mostly talks about an interesting new option for wealth managers, XLR8. Its a custom template written on top of Salesforce.com, the best Internet CRM out there. I *love* Salesforce.com. They have one of the best web UIs around and have been leading the way creating an extensible web-based platform; this is how XLR8 built their product.
In my final weeks at Techfi, I was working on a redesign of our web-based AdvisorMart user interface, largely based on the Salesforce look and feel. Our web UI had always been bad. I remember giving a demo to Morningstar (one of Techfi’s investors), and they were blown away by our desktop product (Portfolio 2000) because it was slick and felt like part of the Microsoft Office Suite. Next I showed them AdvisorMart and they absolutely hated it, recommending a compete from-the-ground-up redesign of the user interface. I ignored them.
My eyes were opened one day when I watched our sales team give a presentation to a big broker/dealer. During the demo they asked our presenter to enter an off-system account in AdvisorMart — nothing complicated, just set up a new account and purchase some securities. It only should have taken a couple minutes but it ended up being the most painful software demo I’ve ever seen.
In a system like Advent Axys or Statement One Albridge, you would:
(1) create a new account, and
(2) enter transactions in a row-by-row grid.
In AdvisorMart, you had to:
(1) create a new account,
(2) create a new asset (new screen),
(3) create a new transaction (new screen),
(4) enter the transaction information,
(5) save the transaction (close the screen),
(6) to create another transaction…
(a) …for the same asset, start over on step (3), or
(b) …for a new security,
(i) save the asset (close the screen), and
(ii) start over on step (2),
(7) repeat until finished.
Holy crap. I’d never realized how complicated that was. After about twenty minutes of trying to figure it out, our presenter gave up. The fundamental problem was that we’d ported the interface paradigm from our desktop Portfolio 2000 product over to the AdvisorMart web product. What worked well in a rich desktop client was virtually unusable in a web browser. And since our own service bureau actually used Portfolio 2000 to import and update the data behind the scenes for our AdvisorMart clients, we had never run into the problem internally.
After the botched presentation, our sales team sat down and compared notes. Apparently, this wasn’t the first time we’d been surprised by the “data entry” request when selling to broker/dealers. Our competitors had discovered the weakness in our product and for months had been tipping off all our prospects.
Over the weekend, I researched all the big web software companies and Salesforce.com far and away had the best user interface for a business app. I quickly built a working AdvisorMart/Salesforce mockup and demoed it to our prospects. EVERY prospect who saw it fell in love with it. The Salesforce interface was so much better that everything else that it created the same intangible “gotta have it” vibe that our desktop software had. Just by adopting the right interface paradigm, we not only fixed the data entry problem, but were going to leapfrog our competition. Our biggest weakness (UI) was about to become a competitive advantage.
Of course this all happened right as Techfi was acquired and the new owners questioned the urgency of redesigning our user interface. I was unemployed before we finished it. The new UI was never released, all our prospects signed with Albridge, and AdvisorMart for Broker/Dealers was the first product to be scrapped. That’s how important it is to have a good user interface.
Back to XLR8.
This is a great idea. I haven’t looked at any of the new Web 2.0 CRM products for wealth managers, but they couldn’t be better than Salesforce.com when it comes to CRM. There are only two advantages stand-alone products have over Salesforce: screens customized for wealth managers and being much, much cheaper. XLR8 eliminates the first problem, but exacerbates the second.
Salesforce is a robust CRM system that competes with Siebel, PeopleSoft and SAP. We’re not talking about basic contact managers like Outlook or Goldmine here. These apps do contact management, document management, lead tracking, customer service management, marketing campaigns, and revenue forecasting. When you add XLR8, they also track:
Insurance Policies (Disability, Long Term Care, Health, Commercial, Life, Umbrella, P&C Auto Boat Plane, P&C Real Estate, P&C Other); Financial Accounts; Annual & Charitable Gifting; Estate Planning Documents; Assets & Liabilities; and Income Tax
It blends the functionality perfectly into the Salesforce UI:
If advisors can afford the platform, it opens up a lot of possibilities. Namely, that somebody could also add portfolio management and trading capabilities to Salesforce, giving the industry a best-of-breed financial office suite.
Andy talks about this potential:
…I’d bet that you’ll see a growing number of applications geared to advisors that will [run on Salesforce.com] over the next couple of years, and independent advisors are likely to be drawn in. It will be built and they will come. It’s only a matter of time. In fact, my guess is that you’ll see a number of large and small tech companies that make portfolio accounting and financial planning applications for advisors integrate with Salesforce.com because it gives them a chance at greater distribution by hooking into it. It’s a way of giving technology firms serving independent advisors a large platform around which they can integrate and produce a “silver bullet” application integrating financial planning and performance measurement and accounting for wealth managers. And it will be produced and distributed independently of any custodian or giant financial services firm.
Now here’s the bad part. Salesforce is *extremely* expensive for a web-based product in our industry. Mike did a post in March about the new Salesforce Wealth Manager version, where a single seat costs $6000 per year — XLR8 isn’t quite that expensive. The XLR8 template works with the standard version of Salesforce.com which only costs $600-1500 per year per user. Plus there’s the one-time XLR8 cost of $1,500 + $350/user.
So the first-year costs for a ten person firm would be $11,000 - $20,000. Compare that to a recent Moss Adams study saying advisory firms with $250,000 - $1 million in revenue only have $5,000 per year budgeted for software expenditures. So I’m naturally skeptical that the product could be successful. But maybe I’m missing something because XLR8 has implemented 25 client firms in the last two years. There’s obviously a few advisors out there who can afford the good stuff.
Any way you look at it, wealth managers have more and more technology options opening up to them. It’s a great time to be an investment advisor.
Bill Ramsay said,
October 31, 2007 at 4:55 pm
That is some nice looking stuff, and my wife uses SalesForce extensivelly in her marketing business.
I’ve done a bit of digging through salesforce developer info, and it feels a bit more like FileMaker than more robust relational systems. I saw references to “mimicking many to many relationships” and SOQL lacking features like ambiguous joins and calculation expressions. I’m not sophisticated enough to understand how limiting that might or might not be, but it feels at first blush like complex functionality would be more difficult. APEX looks like its evolving rapidly, and maybe triggers and business rule layers will be robust enough (and easy enough to implement)?
They also still don’t have an integrated email client, which seems like a big negative for a high end CRM solution.
The concept of hosted platforms for development is I believe absolutely the future- centralized dll management sounds fantastic, but would not Microsoft be very interested in the subscription revenue model? Would SQL be usable for such hosting, then only requiring browser interface development tools to be robust? Given the installed developer base they have, is this the next way for M$ to continue its dominance (if in fact the desktop OS is truly, finally devalued?) Thin clients finally coming back?
Matt Abar said,
November 2, 2007 at 2:59 pm
MS has an interesting project called Astoria that creates a generic SOA web interface for SQL databases. Even better, it runs over their new Entity Framework, which lets you build an queryable ORM on top of a SQL database.
These technologies are the future (if you’re a Microsoft developer). Unfortunately, it will be six more months before it’s practical to really build anything on top of them. But they’re fun to play with.
http://astoria.mslivelabs.com/
http://blogs.msdn.com/adonet/archive/2007/09/04/entity-framework-for-dbas.aspx
I’m not familiar with the Salesforce stuff. I thought it was a solid platform but what you’re saying about “mimicking many to many relationships” sounds lightweight. That would be disappointing. They’re on my list to check out soon.
Bill Ramsay said,
November 5, 2007 at 9:11 pm
Some more interesting things I found
http://www.coghead.com/
http://www.rollbase.com/home.shtml
this next one doesn’t look like a Paas, but the emphasis on rules and the organization of business spaces is rather interesting.
http://www.awareim.com/
not sure about coghead, but i think rollbase and awareim are utilizing Mysql as the DBMS- are these the open source competitors to Astoria?
Is Microsoft close to losing control over end users’ operating system? If I could run thin computers that just need to run a browser, it would save a bunch of time and $ (and sanity).
I’ve been thinking about how salesforce is implementing Paas- in essence it looks like they have a “Fathead” structure in place (CRM), and have created their own proprietary language and dev-environ for folks to build out the LongTails that each customer wants (with the added appexchange opportunity for developers). The limitations may be substantial for non sales apps if their core structure is too sales focused which has thus far defined the typical CRM.