Let’s look for a moment at the reality for an SMB. While traditionally accounting vendors thought of their application as the central core of an SMBs world, and somewhat disconnected from other application types, the reality is that SMBs work in a world that sees them need to utilize lots of different types of applications, and share data and context between those applications. The new QuickBooks mobile app recognizes this and takes a far more user-centric approach to what it does. Over on TechCrunch there is a description but to give some of the highlights:

• Users don’t need to be a QuickBooks customer, the application can be used in a standalone manner
• Finances are just part of what the application does, Intuit have identified that mobile users especially have a far more customer-centric usage pattern and hence the app has lots of CRM functionality
• Again, noting the mobile use cases, the application allows for note and picture taking related to customer activity
• Expenses (and photos of receipts) can be entered on the go
• Customers can be filtered by geographic proximity (yeah, it shows off the mobile GPS bling, but it’s also useful)
• As a nod to the “social feed” trend of the minute, the application includes a feed that gives users insight into recent activity

All this sounds really positive and something of a departure for the traditionally conservative QuickBooks, but here’s where things get murky. When talking about what’s coming next for the application, Intuit suggests that it will likely be integrating its own payments solution, GoPayment into the application. GoPayment kind of works with the application, but only when used as a separate application on the mobile device. Similarly Intuit suggests that data from the wider web (TC suggests Yelp reviews of Twitter updates) and other Intuit partners (ProOnGo or Expensify) will be coming soon.

But there’s the rub, the world, and especially the world of SMBs, has grown accustomed to applications having a strong and vibrant ecosystem early on. The foundation building block for this ecosystem is an open and accessible API that enables and encourages developers and other companies to integrate. This is the very reason that the Small Business Web, a loose industry group of software vendors selling to SMB customers, insists on an API being a fundamental requirement for joining the group – in their view, and a view that speaks to the realities of customer demands – an API is a base level requirement, without that your application is at best a silo that meets the needs of customers, and at worst simply a silo that doesn’t do anything well.

It’s a point not lost on commenters (and, understandably, seized upon by the guy in charge of Developer relations at QuickBooks-rival Xero):

Xero is justifiably proud of its partner ecosystem, it’s got well over 100 different products on the platform, and in doing so has built a compelling way for SMBs to meet ALL their needs (disclosure – I’m co-founder of an accounting migration service, LiveMigrate, that offers migration services to Xero).

QuickBooks mobile versions are lovely, and it’s awesome to see them moving into the more customer-centric parts of back office functionality. But at the moment the application is an island, and in this modern world, no one wants to be an island.

Communities is built on top of the Chatter social platform and covers a number of different functional opportunities – sales, marketing, service and specific verticals that particular businesses may have. As my compatriot and IDC Analyst focusing on the social space Vanessa Thompson pointed out:

Over time, communities will evolve with processes associated to the community becoming embedded in core business workflow processes Salesforce Communities is able to build on the strong base of Sales Cloud, Service Cloud and Marketing Cloud to extend specific workflow and enable an ongoing conversation with customers, partners and suppliers

MyPOV

There is no doubt in my mind that this blending of customer facing with core back office data is a taste of the way enterprise software will look in the future – a plethora of drivers means that organizations have no option but to embrace their consumers closer to the organization and let their sentiment and commentary flow directly into internal conversations, product development and corporate culture. That said, the reality within an organization is that back office is handled by the IT, HR and financial departments while customer facing assets are firmly in the sales and marketing camp. For communities to really be successful – there is a huge amount of cultural change that needs to occur – not only do the technology silos need to be broken down, but so too do the organizational silos need to be.

This speaks directly to a current debate around who will control the majority of IT spend in the future – many believe this responsibility will remain firmly with the CIO. More forward looking predictions suggest however that it will be the CMO that controls much of this spend and, hence, customer facing assets will become a key part of the businesses internal systems. I’m reminded of fellow New Zealand and current CMO of the Commonwealth Bank of Australia (disclosure – CBA is a consulting client) Andy Lark’s comments during the keynote last year at DreamForce. Lark is an excellent example of what I believe will be the future of enterprise IT – a CMO that is a central figure in the procurement and development of both customer facing solutions, and the core technologies that enable those solutions.

The jury is out on how long this new type of enterprise will take to rise and likely it will be longer than Salesforce CEO Marc Benioff would like – that said, Salesforce Communities is a key enabling tool and I’m looking forward to hearing the case studies that will now doubt be writ large at this year’s DreamForce in November.

Part of the reason for this is the comparative capital situation of the two companies – AWS enjoys the cash from its mother ship, Amazon, while Rackspace needs to fund all its own expansion internally. A new initiative the company is launching aims to reduce this capital constraint. Rackspace is going o expand its global footprint through a program that will see the company build and run clouds for third party service providers (telcos and the like). Built to the same specification as Rackspace’s own cloud and, obviously, on top of OpenStack, these cloud will wrap up the technology layer (the cloud operating stack itself, custom tuning for the service providers particular situation and support on the non-technology parts, in particular sales and support.

MyPOV

For Rackspace, if they can make this stick, this is a no-brainer. Capital constraints and the realities of building a global network of data centers have meant that building a competitor to AWS of similar scale has been difficult. With this move the company can leverage the investment other organizations already have in infrastructure and re-purpose that infrastructure to create a virtual global footprint. I t would be interesting to know what this means for Rackspace’s own global expansion ambitions and in particular for the footprint it already has globally – there is potentially an interesting dynamic between a Rackspace owned data center in a foreign location and a Rackspace-built one owned by a third party.

For the service provider this also makes sense – depending on the economics, they are able to leverage a technical partner, a service & support partner and, perhaps most importantly, tap an existing global customer base. Part of the reason we haven’t seen mass scale migration of service provider’s facilities to cloud is that part of the process is a relearning exercise – both internally and externally. This new initiative allows them to use Rackspace’s skills for the all-important internal educational aspects, while also helps them to ease the medium-term customer churn pain. They’re able to gain customers directly from Rackspace. Ultiately it helps them move from traditional to cloud models and beefs up their resource utilization en route.

Of course this all relies on the economics and commercials being right, and we, as yet, have no visibility about how that will look. CEO of Rackspace, Lanham Napier is, of course, talking the partner interest up saying:

We have had interest from service providers on nearly every continent to extend Rackspace’s proven OpenStack powered public cloud solutions and expertise to their customers. It is important to broaden the adoption of open-source technologies through partners around the world. The creation of this network allows for different providers, in different regions, with different service characteristics to link together to better serve the cloud users around the world with a fully interoperable global ‘cloud of clouds’.

Lots of questions remain, and the proof of the initiative will be seen over time but, at face value at least, this looks like a good program – good for Rackspace, good for the service providers and ultimately, good for global customers who want more granular options over data location.

It is for this reason that when Xero launched in its home territory of New Zealand, the deal it had secured with a number of loal banks for auotmed bank feeds was just so game changing. Bank feeds are supremely useful, and by spending time negotiating the deal, Xero had given itself an awesome launching point. The global reality however is somewhat different, and it’s fair to say that Xero didn’t have the same success convincing banks outside of NZ to come on board, hence their decision a few years ago to use the Yodlee platform to run their bank feeds. this was a logical decision (Yodlee, now owned by Intuit, is a banking integration platform that already has thousands of banking institution integrated into it Clarification – Intuit’s DOES have a bank aggregation service through it’s acquisition of Mint but it’s not Yodlee).

However, we’re talking about money here and, as is always the case with dollars and cents, a higher degree of suspicion arose. This was especially so given the deftly overlooked fact that, by using Yodlee, a customer is potentially in breach of their banking terms and conditions. This is due to the fact that to use Yodlee, internet banking login details need to be given by the customer to the Yodlee platform – a fact which contravenes many internet banking Terms of Agreement.

But time moved on and, despite some concerns in the odd online forum, customers kept signing up, and enjoying the benefits that automated bank feeds can bring. Which gets us to the announcement from FreeAgent that they too are using Yodlee for their bank integration. It seems to me that, regardless of the reality of a situation, there is a point at which perception gets tipped by critical mass. Clearly using Yodlee is, by the letter of the law, a contravention of a customers internet banking terms and condition. But customers seems to be deciding (either because they are ignorant of the implications, or because they are realistic about the very low levels of risk involved) that it is worth it to achieve the benefits that integration can bring.

It’s completely sub-optimal of course. In any other industry we would be incredulous that a third party site needs to be given full sign on credentials imply to perform a data transfer – but it’s symptomatic of an archaic and compliance-heavy system that doesn’t exactly encourage innovation and open mindedness. It’s a sure bet that both Xero and FreeAgent would be over the moon if a more robust integration was possible on a broad scale, but all things being equal, for the time being they’re happy leveraging the industry default, Yodlee.

And what about the customers, should they be worried? Well I’d suggest that most customers who would balk at using Yodlee for bank feeds would also balk at entrusting their accounting data to a vendor who stores their information in the cloud. But for the vast majority, perception is actuality, and the fact that many vendors, and hundred of thousands of customers have grown comfortable with Yodlee has flipped their perception to one of safety. Let’s hope that a justified perspective.

Awhile ago I reached out to a series of SaaS accounting vendors to get their different perspectives on what they’re seeing with regards to churn. I thought their comments were broadly applicable to the general SaaS space and so I’ve pasted them below (without specific vendor identification). I’m keen to hear others thoughts on the issue of churn for SaaS.

Vendor 1

Here are our thoughts currently: The first issue is what constitutes a sign up. For us it is a full completion of the registration form. However as you know, churn is a tricky thing in the accounting space, and specifically for us with a small business accounting product. The biggest challenge is determining what a lost or lapsed customer looks like, vs a customer who just leaves accounting or bookkeeping until it piles up.

To put a face to that: Imagine that Jane signs up in January and does a whole lot of work. February, March and April go by and she hasn’t come back. We have no way of knowing whether she has abandoned us, or if she’s just busy with other things. Maybe she’ll come back in another month and get caught up, or maybe she’ll only come back once a year.

Coming back only once a year isn’t great for Jane (accounting is way easier if you stay on top of it), and it isn’t great for us either. So we have strategies to encourage Jane to come back more frequently. But if she doesn’t, we’re not prepared to throw her under the bus just yet.

Those facts, combined with the fact that we only launched recently, mean that we haven’t written off any customers yet. Unless a customer has overtly cancelled the account, we’ll continue to protect their data, and to find ways of re-engaging the customer, to either come back and get caught up, or to close the account for good.

Vendor 2

I’d always thought a sign up to trial, a conversion to paying, and a lost customer was pretty black and white. It’s only recently I found out various companies don’t count a sign up to trial unless they log in more than twice, don’t include them in churn figures if they only paid for 2 months before quitting, etc. Clearly some vendors are re-writing history and creating self-serving statistics.

Vendor 3

Currently we get about 100 new ‘trial users’ a month. Out of that 100, about 50% of them never even really try it out, they log in once to look at it but never enter data and never re-log in, never really sync or integrate with any of our integrations, so no real trials. 10% of them are fake names, company names and information – don’t know really (never paid too much attention) if they are spammers or competitors or what have you. Out of the remaining 40% it depends on the season, during tax season we convert 35 of the 40 to paying subscribers, outside of tax season we convert about 15 of the 40 to paying subscribers.

Out of the paying subscribers we get approximately 50% cancel within 3 months and the other 50% stay on for a year or greater. So out of every 100 trial users we get about 35 paying users temporarily and about 15 long term paying users (during tax season)

Out of tax season for every 100 trial users we get about 15 paying users and about 7 long term paying users

Vendor 4

We see monthly cancellation rates of between 1 and 1.5% of the total user base as at that month – it’s an explicit ‘cancel my account’ button that has to be pressed. That’s not quite the same as the monthly churn rate but not far off, I think. On top of that there are ‘suspended’ accounts against expired credit cards that haven’t been updated. The number of ongoing suspended accounts (implicit churn) is somewhat lower than the explicit cancellations.

Obviously we want to make that as low as we can, and we follow up where possible on all of those – from an information point of view, we rarely recover them once they’ve cancelled. We working on a more accurate model of churn – looking back by monthly cohort and calculating the total proportion of customers who signed up with us in, say May 2010, and who have since cancelled. This gives us a better feel for the seasonality of cancellation – are people who join us in April (start of new tax year) more or less likely to stick with us?

In general we’re not hearing about customers leaving us for our competitors but rather moving away from the business, or leaving freelancing, back into employment. That would seem to accord with statistical business survival rates etc: a mean lifetime of 5 years sounds about right (reciprocal of 1.5% churn = lifetime of 66 months) We mostly use that number for thinking about customer lifetime value from the viewpoint of understanding acceptable customer acquisition costs.

Also we’re trying to get a handle on pre-churn alerting – what do users do (or not do) before they cancel? Maybe they stop generating invoices for a month or two, in which case can a well-targeted email or call head off that line of thought?

Which is why the announcement a couple of weeks ago that SAP would be giving its Business Suite customers the option to both captures and analyze transactional data in real time on a single in-memory platform. Essentially, Business Suite using HANA allows organizations to run their businesses in real time and perform the trifecta of transacting, analyzing and predicting on one system. If the 80’s was all about the “continuous improvement” buzzword, product like this actually allow continuous improvement in IT to occur – by intrinsically tying together the end-to-end business processes that generate the data itself. It doesn’t hurt either that by unifying these formerly discrete functional areas, organizations are able to reduce duplication of data and simplify their systems.

In pitching this offering, SAP is articulating three core themes and benefits:

• Smarter – real time big data management, efficiency gains across supply chains, predictive smart analytics
• Faster – business processes, insights, decisions
• Simpler – Suite on HANA radically simplifies IT. Moving all applications onto the HANA platform to close the data divide between analytical and transactional world.

It’s very early days, SAP is releasing this gradually and currently targeting early adopter customers – they’re promising more general availability in Q2 however. Initial customers include John Deere and Ferrero.

MyPOV

Providing customers with near-real time insights into their data is something of a holy grail for technology vendors. If SAP can truly roll this out on a widespread basis, the impact will be significant. Given SAP’s considerable market-share, this move is both a massive opportunity for SAP to expand its footprint within existing customers, but also a threat to other enterprise BI providers who will feel the pinch from customers questioning the need for a standalone analytics suite.

Cost is something of an unknown – SAP will need to work hard to avoid it’s traditional temptation to charge in an aggressive and complex manner. To truly succeed, the pricing and licensing should be simple to avoid barriers to adoption. Add to that the unknowns around training and migrating from existing analytics products and there is some murkiness around how this will actually work.

SAP also needs to overcome the conservatism of many of its customers – the ideal way to do this is through articulating the benefits and giving customer a very low risk and low cost way of seeing for themselves the benefits that connected transactions/analytics platforms can bring – again this goes back to the licensing and pricing models.

SAP has long been mocked by other enterprise vendors for being a laggard when it comes to the cloud – rather than come out with some cloud-washed application however they’ve looked hard at how they can deliver real value to customers. Running Business Suite on HANA provides a credible means of differentiation and sees SAP playing, to use a sporting metaphor, to where the puck is heading. It’s going to be interesting to see the customer uptake for the extended product suite.

The Cloud Database Wave findings can be seen below:

So far so good right? Except when you dive into the methodology. Let’s take a look at one of the categories upon which Forrester scored products, that of multitenancy. Multitenancy should be a very simple test – either a product IS multitenant, or it isn’t. There wouldn’t seem to be any gray areas in there right? Well, actually no. The Forrester scoring goes like this:

Describe the product’s multitenancy model to support cloud databases. Is the cloud DB offering a multitenant implementation, or is the offering a dedicated database running in a VM? Does the vendor support both modes? Describe how customer data can be isolated (i.e., into specific servers, storage, partitions, shards, schema, table or rows). Can customers put their data on dedicated infrastructure on the public cloud? Does the service provide “dedicated compute/memory capacity”? Are customers able to view metrics such as disk I/O and read/write latency?

Forrester gave products a multitenancy rating as follows, with 5 being a perfect score:

5 = Natively supports both dedicated full database platform running in a VM environment and multitenant database. Supports complete isolation of customer data into specific servers, storage, partitions, shards, schemas, tables, and rows in a multitenant database. It also allows customers to put their data on DEDICATED hardware that’s separate from other customers on the public cloud. It also allows for dedicated compute and memory capacity and resources that are separate from other customers. Customers can view metrics such as disk IO and read-write latency using tools.
3 = Supports either the dedicated full database platform running in a VM environment and multitenant database. Supports complete isolation of customer data into specific servers, storage, partitions, shards, schemas, tables, and rows in a multitenant database. It also allows customers to put their data on dedicated infrastructure that’s separate from other customers on the public cloud.
1 = Supports either the dedicated full database platform running in a VM environment and multitenant database. Supports complete isolation of customer data in a multitenant database.
0 = Supports no multitenant database facility.

So essentially Forrester is determining multitenancy is a worthy category on which to score products, and then also determining that products that a completely focused on multitenancy are sub optimal. I mean I kind of get what they’re saying here – the products that offer the widest selection of deployment options to customers are preferable, but in scoring down multitenant-only products in this classification, they are making a judgment call by saying widest applicability trumps most focused multitenant execution. This perspective is even more strange given one of the key takeaways they came up with:

Cloud databases are Not a database in a Virtual Machine – Cloud databases are fully automated multitenant services that present a database capability but are managed under the covers, giving, to varying degrees, elastic scale, performance, and availability management and programmability on a pay per use basis

So the key takeaway that Forrester came to, namely that a cloud database shouldn’t be thought of as a database in a VM, was completely disregarded in giving pureplay multitenant vendors a lower score than those who deliver database-in-a-VM functionality. Does. Not. Compute.

So what’ll it be Forrester, will you back yourselves when you say that a real cloud database is one which is fully automated and multi tenant, or will you continue to be an apologist for the all-things-to-all-people crowd?

And the Zendesk approach would seem to be right – the graph below shows the relative volume of service ticket origination for Zendesk’s own support organization – the rapid growth of the voice channel shows just how important it is for end users to be able to dial a number and talk to someone.

Over its customer base, Zendesk reports that 1695 accounts are using voice across 64 countries and that, in the year since launch, 20000 hours of call time has been made to these voice-based channels. Zendesk Voice is made possible by another one of the super stars of cloud and API driven disruption – Twilio, a company that is disrupting traditional telco providers by enabling phone, VoIP, and messaging to be embedded into web, desktop, and mobile software.

Anyway – all very empowering stuff and exciting that Zendesk’s Kiwi customers (and, from what I hear, they have quite a few) will be able to enjoy the service too. And the pricing makes it pretty attractive – Zendesk can get an as-a-service multi channel support offering with voice pricing set at $0.013/minute for voicemails, $0.016/minute for calls to an agents softphone and $0.063/minute for calls to a physical phone.

Living in New Zealand, and spending as much time as I do in the US, it’s sometimes a little depressing just how many cool services we can’t use at home (Google voice anyone?). It’s awesome that New Zealand Zendesk customers are catching up to their equivalents over the Pacific.

In the post, the IT practitioner said that:

I’ve been involved on the periphery of several RFP responses, Statements of Work etc. that relate in one way or another to government agencies and large corporations outsourcing their infrastructure hosting to a provider. I’m not talking here about equipment co-location, but rather scenarios where the hosting provider owns the tin and truly delivers the Data Centre Infrastructure as a Service, including the storage. No doubt this is a growing trend both here in NZ and globally.

Nowhere during my involvement, which as I said has not been in-depth, have I come across descriptions, or requirements for that matter, on the “exit approach”

So I’ve been sitting here pondering, when the relationship between the customer and provider comes to an end after say, three, five or 10 years, and the customer has 100, 200, 600 TeraBytes of data sitting on the equipment (a SAN one would expect) owned by the incumbent provider; how on earth would they go about migrating this to the new infrastructure or archiving it off for later access?

Keen to hear people’s thoughts on this.

It really is a valid point. We all spend a lot of time worrying about getting our organization to start using a cloud service, but what happens when we amass vast quantities of data on that service and want to shift? Network limitations are such that this can cause real issues. It’s interesting to note that many cloud vendors allow customers to send data on tape or drive to the vendor as the fastest practicable way to migrate data across – if this approach needs to be taken at the start of a cloud relationship, imagine how much more important it is after a period of usage.

I’d be keen to understand whether organizations are thinking about this issue and, if so, what they’ve done to resolve any potential issues. Feel free to comment below.

An added part of the roll out however was the introduction of a link at the top of online invoices which takes customers to a customer portal where they can see their invoicing history and amounts outstanding. Again a super valuable addition to the product. Things got a little unstuck however due to Xero’s understandable desire to track an audit trail around who is opening these invoices. The “link to other invoices” button takes end customers (ie the customers of Xero users) to a page which allows them to either login to Xero (if they’re already a user) or set up a free Xero login that gives them access to their invoice history.

This is a seemingly innocuous step, and one which, after the small hurdle of registering, will drive some real efficiencies for businesses. The problem, as shown from the large number of comments on the Xero blog post is that this is the first time that the customers of Xero users have been presented with anything that specifies the origination of the invoice. Previously emailed or printed invoices came in a fairly generic format that could have come from any number of accounting solutions (or a word template for that matter).

A number of commenters then saw this move as an attempt by Xero to utilize their business (ie the business that is a Xero customer) as a business development and sales channel. The account setup requires end users to create a Xero account – in this day and age when customer loyalty and customer data is sacrosanct, a number of people balked at the suggestion that Xero would, in essence, have a direct relationship with the customer. Xero justified this step by saying that:

The reason we require a login to view outstanding invoices is to give you an audit trail of exactly who has viewed those invoices and when they were viewed.

I’m not completely convinced the audit requirement argument is valid, if full audit trail was required then Xero wouldn’t be happy to email an invoice which can be forwarded ad infinitum. As it is, invoices are insecure and I would be surprised at any concerns from Xero customer in the event that the link to invoice history didn’t require a login.

In hindsight (and isn’t it always a great thing?) Xero would probably have been wise to have the “link to all online invoices” and hence the invitation to setup an account with Xero deselected by default – as it is removing the link from all invoices is a fairly complex and convoluted process that is likely more than many Xero customers really want to contend with.

Kudos to Xero head of design Phil Fierlinger who quickly wrote a post that detailed some of the thinking behind the functionality. There’s an interesting thing to look at here though, Xero now has over 100000 customers but has ambitions to service millions of customers – as they look for new ways to grow, introducing these sorts of viral features becomes attractive. In fact this is the way that their competitor FreshBooks has grown to its massive size. The difference is that a huge number of FreshBooks customers are using a free service, they expect that FreshBooks will, to a degree, leverage their networks to grow. The technique sits uncomfortably with Xero’s customer who are paying for the service. As one commenter said:

We pay a monthly fee – so in my view it’s not reasonable to use us to advertise your service. I think the online invoice should be on an unbranded domain without Xero links unless I choose to add them.

The bottom line is that online invoicing is an immensely useful tool and will be seen as the default way to do things in the future. But introducing new functionality like this needs to be done with a lot of thought, and vendors should always err on the side of caution, especially when attempting to leverage their customer’s customers. I suspect Xero will look at this release and think about the way it approaches these sorts of changes in the future.

A video of the workflow is embedded below

Sales Invoices from Xero on Vimeo.