We’ve already talked about when it’s time to customize Salesforce, when it isn’t, and the branding impacts of your Salesforce interface, but today we’re looking under the hood. If you’re customizing Salesforce, the backbone of your entire project is setting your technical goals and analyzing your data. Don’t make development an afterthought - let it take center stage. You’ll thank yourself through time and cost savings later.
When we sit down with a client who is ready to customize their Salesforce experience, we follow a basic, iterative process:
Modification or a Blank Slate?
It’s critical to know, up front, if we’re working on an existing system and existing customization. Sometimes, a blank slate is easier because we’re not interacting with complexities of an existing system - that said, sometimes a pre-existing system leads us directly to one solution by process of elimination.
Where’s Your Data?
Reports, charts, graphs, and automation are useless without good data. If you put spoiled food into a great recipe, the end result will still give you garbage. At the heart of your Salesforce customization effort should be the ultimate goal of having pristine and helpful data. We review with you:
- What data you currently have
- What data you want
- What information you need from your data
- How data is being collected
- Where your data may be corrupt
- The best way to present your data
- How your data is created/input
Once we have identified clear parameters on your data, we investigate your goals. After all, clean data is only as useful as its presentation. The same data presented in two different ways could help make key business decisions or spawn intense confusion. We consider:
- What are you trying to achieve?
- Can you tie those goals to specific business outcomes?
- What KPIs are most critical to the success of your organization?
- What is the ideal end state for your business and how can data help move you in that direction?
Our Experience: Heroku
The LookThink team worked with a small arts-focused university in the Bay Area to develop an app that helped students locate campus shuttles, plan trips, and monitor shuttle schedules. Upon reviewing the data they were currently receiving, we mapped that against their desired outcome. As part of our solution, we integrated Heroku into the client’s Salesforce system. Heroku allowed us to take data from multiple sources (the client’s newsfeed, bus schedules in their Salesforce, and data from the transportation API) and feed the app with up-to-date, complex information, presenting it in a unified way. By starting with our client’s existing data and their desired outcome, we found a powerful development solution which drove design and UX.
Your data isn’t the only thing to consider – now we’re considering how your data is already being structured, whether in Salesforce or not. How does your system play into your processes? How is (or isn’t) the data flowing through the system?
Once we map your current system, current data framework, and intended goals, we identify areas where Salesforce, used a different way or new components, could potentially achieve your business objectives.
A Requirement for Requirements
Once we know what your data is and what it needs to do, we create a requirements document that also considers branding, user experience, business processes, industry norms, and a host of other elements.
This requirements document not only serves to identify conflicts between requirements and limitations of the data or system, but it also serves as a lifeline to preserving the scope. It should be a living charter between the needs of the company and the limitations of the software: in this case, Salesforce.
Especially if we’re starting from scratch, we consider everything available to us – various licenses, different components, pending updates, or new releases, and we map each requirement back to a piece of Salesforce. The gap between what out-of-the-box Salesforce is available and applicable and your requirements indicate just how much customization needs to happen.
In the end, our goal is to make sure that the custom pieces are truly doing what Salesforce, in any other way, isn’t. We don’t believe in fixing what ain’t broke. (We talk a bit about that here.)
If you’re working with an existing Salesforce installation, we identify where your existing Salesforce components are and aren’t working – which dependencies or new components we can leverage and where customization can save time and money and improve processes.
Our Experience: Complex Requirements and Iterations
One of our clients is Washington DC’s Briya Public Charter School who needed an online system to replace their disparate and laboriously manual data collection processes. Data thoroughness and accuracy were paramount since the data needed to be reported from the new online system directly to the grant funding agency.
Identifying the system requirements from the perspectives of both Briya and the grant funding agency was a challenge. Different user groups had unique priorities and reporting needs. We documented these requirements for the input, storage, display, and reporting of data in the new system and tested solution ideas with the user groups iteratively at increasingly detailed levels. As we received feedback, our requirements documentation shifted to best reflect the nuanced needs of each group.
Our solution not only had to collect the right data, but also collect it in the right way. It had to integrate into teachers’ and administrators’ existing workflows. The fields and flows for inputting information couldn’t be clunky or too foreign for the different user groups, but also had to be consolidated into a single system with a few key flows representing the needs of all of the groups.
We started with different teachers, administrators, and staff working in separate Excel spreadsheets and have mapped those requirements back to a larger, Salesforce-based solution. This consolidation ushered in new processes for the users, but alleviated clunky, disparate data-entry as well as enabled streamlined reporting.
Our client’s original business problems were unearthed and documented through initial intensive workshops, which allowed us to construct a high-level data architecture to support iterative development. What started as a collection of goals and a data roadmap turned into flexible requirements documentation validated iteratively throughout the development phase.
One More Time – Iterations
Since development is the backbone of your project, we approach the development-heavy phase of a Salesforce customization in an interactive process. We’ll talk more about the information architecture and user experience components of a Salesforce project in later blog posts, but we start with prototypes based on development-possible solutions, informed by careful data analysis.
We then build our solutions piece by piece, ask clients to test it out and provide feedback, and determine if their problem is actually solved. Sometimes, solving one problem brings to light to a new problem; in an iterative approach, this early discovery to previously unknown issues saves time and money and allows for the architecture of the project to react to the expanded requirements. Sometimes, you have to take something for a test drive to realize that maybe it’s not the right approach. With iterative testing taking place early in the process, it’s far more flexible to accommodate changes.
We understand that business processes are constantly changing, and your industry, competition, and clients are more fluid now than ever. That’s why we go step-by-step, allowing for feedback and modification with an eye on the living requirements document.
When you’re approaching a Salesforce integration, a customization effort, or custom app, take the time to review everything from a development standpoint. We bet you’ll find the ROI more than makes up for it.