You know you want it. How to get it. Now.

ROI Calculator

You just know that Elements will make your life easier, but that is not really good enough. Your boss needs a business case and then you need to find some budget. So you need a clear understanding of the ROI – the costs and the benefits.

But we can only afford free

Rarely is free ever free. There is ALWAYS a cost, even if it is not a financial cost to purchase an app. So, you should evaluate that cost and be able to build a business case or justification for the approach you have chosen.

Many just opt for a “free option” because it is “easy” or “we don’t have any budget”. But maybe spending time building a business case is easier than struggling with “free” especially you add up all the costs.

The costs are

• Financial  –  Buying the app, so the license costs per editor, user or Org
• Time  –  The effort required to build, support, enhance and document. The effort to learn and use it. The effort to work around the limitations.
• Risk  – The risks which could be operational, technical or security

Costs of risk

• Operational – Is it slowing down the ability to deliver apps quickly? Does it support the implementation lifecycle properly? Are we missing opportunities? Is this app strategic and if it stopped being available / working is that an issue?
• Technical –  Does it fulfil the requirements in terms of functionality, architecture and scalability?
• Security – What does the approach expose us to in terms risk or liability?

Options and hidden costs

Let’s look at the options and (hidden) costs of each “free” approach:

• Existing office tools – DOC, XLS, Quip; you already have licenses for tools like MSOffice, GoogleDocs or Quip. But these are not apps. There will be manual effort to work around their functionality and security limitations.
• Build your own – You have the skills to build anything in Salesforce. But there is the effort to support and enhance. Oh — and document.
• Non-ISV developer – An app built, supported and maintained by someone in their free time. How do you rely on this? What happens when their circumstances change so they no longer have as much free time? What is the roadmap and how quickly will they respond when changes are made to other apps they integrate with i.e. Salesforce changes APIs? How do they support customers?
• ISV Open source – An app built, supported and maintained by a collective in their free time or a company who make money out of support. This has some of the issues with the previous point, and/or it is like a paid app, but with a different pricing structure.
• ISV Freemium – The free app is a teaser to get you to pay for the full functionality which has a cost. Or to buy another app from the company. Be clear, freemium is a marketing technique.
• ISV “Free not Free” –  There are apps on the AppExchange listed as free where free means freemium or free 14 day trial. Clearly not FREE. The AppExchange are starting to make sure that the true cost is clear, but there are a lot out of apps listed as free.

Question: Why not build your own CRM using free tools like XLS rather than invest in Salesforce? Surely the same arguments apply? Answer: We need more functionality than a simple XLS.

Question: If there is an ISV with team of developers building and maintaining an app which has a roadmap of enhancements from customers, then why do you think you can build something yourself alongside everything else you are doing Answer: You may have far simpler requirements or you have underestimated the effort/cost/risk.

The going in assumption should be that if there are ISVs that have a paid product that customers are using, then there must be a good reason. When you look at a free app and think “this is too good to be true” then you are probably right.

Building  a business case

Just because you don’t have financial budget you shouldn’t just put up with office tools or just look for free apps. You may be able to build a business case for purchase, based on the effort taken to use free apps and the opportunity cost.

How to build a business case to buy an app:

• Be clear about your requirements BEFORE you start looking for apps. What are must haves? What compromises will you make?
• Understand and quantify the time savings, reduction in risk effort, lost opportunity cost of using an app vs free.
• Run a pilot/trial to validate the app vs your requirements and the value
• Phase the roll out. Start small with a tightly scoped pilot to minimize license costs from which you can get the data to build a bigger business case for roll-out.

Show me the money

There are 3 areas to look for measurable benefits; business analysis, clean-up & documentation, and feedback & training. Some of the benefits are cumulative.

Business Analysis

This covers process mapping, data modeling and requirements capture. Our experience is that companies can get up to 25% business productivity improvements simply by streamlining operational processes and removing waste. That is without implementing new apps.

There are huge benefits if you get a clear understanding of the operational processes BEFORE you start configuring. First you get the benefits of streamlining the processes which will give you immediate productivity improvements. Secondly you avoid expensive rework because you are building what end users really need – not what they thought that they might need. You will be surprised how much the requirements change once you really lock them down in the context of the business processes. Next, the process maps and linked information is valuable training material so end users can find what they want more easily. Not surprisingly this is the largest benefit. Finally, the process contents supports your regulatory compliance.

Clean up & documentation

A recent IDC report called the Future of Work estimated that “40% of development time is spent dealing with ‘technical debt’”.  The root cause analysis of the 450+ OrgConfessions is eye-opening. Poor business analysis and a lack of documentation are #1 and #3.  Both of these a major contributors to technical debt.

What is not included in the 40% that the IDC survey identified is the effort spent on impact analysis of every change because you have no idea what fields are used. And then there is the firefighting when you make a change and the Org breaks unexpectedly. You are fighting objects with maxed out fields, but you’re guessing many of them are never used. Or you are trying to debug an automation. This slows everything down.

Users could be more effective if page layouts didn’t look like CVS receipts due to the number of fields. Finally, there is the time wasted looking for documentation stored on shared drives. And once you have found it, can you be confident it is the correct copy?

A study back in 2008 by Herman Miller commented the time lost by “information overload” is 20% for knowledge workers. And that has only gotten worse with the proliferation of apps where documents could be stored An industrial client ran a test and discovered that our process-led approach to documentation made it 34x faster to find the right information in context. And that last word is crucial “context”.  The best place to find a spec is attached to the meta data items that are impacted.

Feedback & training

You’ve spent all that effort on building the app and if the end users don’t use it properly you end up with poor data and awful adoption. What is the cost of fixing data? What about responding to the same questions again and again? Have you estimated the time wasted with end users struggling to use the app?

We’ve built a simple ROI calculator.

The morale boost and increase in adoption from responding really quickly to end user feedback should not be overlooked. It all starts with engagement – giving end users a really easy way to post feedback, inside the page layout. Capture the feedback and voting on the quality of help.  Then provide updated training material or tweaks to page layouts really quickly to show you are listening.

There are some simple, quick wins.  Removing unused fields from page layouts speeds up load time, reduces end user visual overload and the potential for poor data.  Finally, target the key fields where data quality is critical or there is end user confusion; picklists, mandatory fields, fields that kick off workflow.  Provide additional help that is easily accessed in context.

The Herman Miller story of information overload is just as relevant here. The sales team will be more effective if the published proposal template is linked to the Opportunity object or a step in the proposal process which is accessed inside Opportunity object.

Lightning Migration

There are clear business benefits when you migrate to Lightning. Salesforce’s own research of over 500 companies who had made the switch makes compelling reading; 31% less time managing pipe and 28% less time standardizing processes, with 21% uplift in win rates, 29% faster reporting, 40% improved collaboration, and 41% higher productivity.

So if you could migrate to Lightning faster by quicker org analysis, could you pull forward these business benefits? What is. the business value? These could easily overshadow the benefits of the reduced migration effort.

Where to look for budget

It is not just the Salesforce tools/apps budget pool you can fish in. There are other places to look. There is an operational/business improvement angle. You could look at training budgets. Can you tap into other business areas for budget? Remember, Elements Catalyst is not just Salesforce, but covers all business areas and systems.

Photo by Micheile Henderson on Unsplash

[/spb_text_block] [/spb_row]