Build vs. Buy Considerations for Higher Ed

BY: Jace Bryan, Higher Education Advisory Council Member, Texas A&M University-Commerce, @JaceBryan_

This is the second post in a series of Salesforce Higher Education Advisory Council blogs surrounding the Build vs. Buy discussion. Check out the previous blog in the Build vs. Buy series.

If your Salesforce CRM story is the same as mine then you are in for a real treat. If not, no big deal! You will still learn 8 common Build vs. Buy considerations facing Higher Education along with examples from a Salesforce Higher Ed Admin at Texas A&M University-Commerce. So sit back, relax, and be prepared to be amazed! There are indeed many #SalesforceHigherEdLoveStories in the world of CRM and today I have the pleasure of telling you mine.

For those new to Salesforce (or those already using the Salesforce ecosystem) I would like to take a moment to introduce you to the Salesforce.org Higher Education Advisory Council (HEAC).

The Higher Education Advisory Council collaborates with Salesforce and industry partners to make Salesforce work for Higher Ed. They fulfill this mission by:

• Leveraging our collective higher ed, IT, and Salesforce expertise to make a difference on our campuses
• Maintaining a collaborative community that shares code, best practices, and documentation
• Identifying needs and advocating for solutions
• Connecting with new and prospective Salesforce Foundation higher ed customers
• Participating in outreach efforts through webinars, blogs, Higher Ed Summit presentations, Force For Change Grant applications, etc.
• Recognizing the diversity of functionalities and needs of higher ed institutions

The Higher Education Advisory Council recently divided into subcommittees to focus on important and relevant topics impacting the world of Higher Education in Salesforce. This blog was created by the Lead of one of those subcommittees, the Build vs. Buy sub-committee, whose goal is to bring important, relevant and helpful information to the surface in the context of making a decision in the build vs. buy dialogue. I am the Lead of the Build vs. Buy subcommittee and this is my build vs. buy consideration story.

Assumptions

I am making the following assumptions about those reading this blog:

1. You are in Higher Ed looking for a CRM solution; OR
2. You are in Higher Ed using Salesforce and are considering how to go about extending functionality with an implementation partner, vendor partner or manage package; AND/OR
3. You are interested in the Build vs. Buy discussion and want to know more about it.

What is the Build vs. Buy discussion?

“To build or to buy – that is the question.” – Me

All Universities will eventually face this question. In my experience I’ve seen it happen in 3 ways:

1. When a University has selected Salesforce as their CRM of choice and are trying to identify if they should go with native Salesforce functionality based on their business needs;
2. When a University is already using Salesforce and are looking to add additional functionality but have no internal resources to address the need; or
3. When a University is already using Salesforce and is looking for a total packaged solution that resembles pieces to the Student Lifecycle (i.e. Recruitment, Retention, Advancement, etc.…)

To Build (in a nutshell)

To go with a “Build” solution is to customize Salesforce to match your organization’s business processes. In the build scenario, you scope a solution (with or without an implementation partner) and focus on building out your needs piece by piece until the whole picture comes into view.

To Buy (in a nutshell)

To go with a “Buy solution” is to identify that there are “ways” of doing “things” in Salesforce that are not part of native functionality AND rather than building out individual pieces to a Student Lifecycle puzzle you would rather adjust your business processes to match Salesforce’s native functionality, or you utilize a pre-built customization (an application) that covers the student lifecycle gamut. Rather than focus on building out your needs piece by piece, you go with a total solution that includes all (or many) of the pieces.

What about an implementation partner? Are they part of the Build vs. Buy discussion?

It depends. If you’re planning to use Salesforce “out of the box”, or if you’re planning to utilize internal resources at your University to build out Salesforce for your team, then no. However, if you plan to use an app (a “buy” solution) or if you plan to customize Salesforce to match your business processes and you do not have an internal resource who gathers those requirements and implements them into your Salesforce org (a “build” solution), then yes.

4 Build Considerations

The Higher Education Advisory Council’s Build vs. Buy sub-committee has pooled their resources in order to provide 4 common considerations for Universities to use when considering a Build solution.

Consideration #1: Do you understand your current business processes and how those translate into your business needs?

When Salesforce was first introduced to Graduate Recruitment at Texas A&M University-Commerce, business processes, business requirements, and business needs were still being defined. We were working with a series of disparate spreadsheets owned by individual Graduate Recruiters who were each tracking different things differently. Translating the business processes, requirements, and needs to processes within Salesforce proved difficult. What we soon realized was that in order for us to work collaboratively (and strategically!) we needed to identify commonalities that represented Graduate Recruitment as a whole. Over a series of weekly meetings, we were able to identify common terminology, common fields, common business processes, common business requirements, and common business needs in which to satisfy the Graduate Recruitment process at A&M-Commerce.

We used this same approach when we began discussions on reporting. Rather than create one-off reports for each Recruiter, we focused on continuity, and the shared data each college needed to report on. In the end we created 10 reports referencing the same fields and report structures (Tabular, Summary, Metric, Joined) with the only variation being the Lead Owner (i.e. College). With reports in place, we began building out each Recruiters’ Dashboard. From here the Recruiters were free to begin creating their “one-off” reports as they saw fit.

The key to this consideration is knowing what you know and recognizing that there are things that you don’t know. Once you put that on the table, it is easier to move forward with a team who can then creatively identify what it is they would like to see, experience, and understand, as well as what it is they are attempting to achieve and measure.

Consideration #2: Does your organization have a CRM Road Map?

Once we had our business processes and needs identified and were working toward building out our “vision” for Graduate Recruitment in Salesforce, we quickly realized that our good intentions were not going to be enough. We needed to cast our vision wider. Our Graduate Recruitment activities needed to be understood, AND we needed institutional support in order for wide-scale adoption to take place, and to ensure our continued success and adoption of this CRM solution. The concept of a CRM Roadmap was very new to us, and left us with many questions to answer as we only knew what we intended for Graduate Recruitment and not the rest of the University. In order to better understand how other Universities were defining their CRM Road Maps, from an Institutional standpoint, we researched many Universities who were using Salesforce in that manner. What we found with Pepperdine’s Engaging Waves (CRM) Initiative was a template for adoption that covered the areas of: Vision and Strategy, Position Statement, Timeline, Executive Sponsors, Program Committee, Governance, FAQs, and Blogs.

Check out Pepperdine’s Engaging Waves (CRM) Initiative.

The Key to this consideration is to identify early on what your institution needs from a CRM standpoint, then bring in those who will most likely benefit from that solution. During this process you will not only identify process owners but you will also identify the sponsors who can bring the vision to a reality by helping to paint the picture of what a connected campus can look like. Those sponsors can also help champion budget proposals to acquire the funds to build or buy.

Consideration #3: Does your organization have the right technical in-house resources?

Salesforce was introduced to Texas A&M University-Commerce based on an implementation done for one of our sister schools: Texas A&M University-Texarkana. Luckily, our technical in-house IT resource was the one who assisted in their initial implementation, and he was able to walk us through all the awesome features and capabilities of Salesforce based on what we were looking to accomplish. However, this resource was not enough: we needed someone who could also administer the system, provide training, drive adoption, and assist in building out of the vision at the campus.

Once an Admin was identified (that would be me!) we started to think about the next phase of our pilot: SIS integration with Salesforce. Here are some questions that came up:

• Does IT have knowledgeable AND readily available resources to assist our Admin with data extracts?
• Who can we use to extend native Salesforce functionality with VisualForce and/or APEX?
• Who would write any needed APIs?
• Who will handle the security when it comes to needed integrations?

The key to this consideration surrounds knowledge of available resources and if additional resources are needed in order to accomplish the project’s goals (short term and long term).

Consideration #4: Has your organization established support resources/teams for maintenance, new feature requests, and onboarding/training?

Your organization needs more than just the right in-house technical resource. Your organization also needs support resources/teams to support maintenance, new feature requests, as well as onboarding and training. You may be asking yourself if you can use the same technical resource mentioned in Consideration #3. And that’s a great question to ask! Many Universities have asked themselves this same question. And the answers range from a resounding YES to a firm NO…
For those Universities who say YES:

• You are strapped for resources and cannot afford to hire an additional person to provide maintenance, handle new feature requests and onboarding/training support services.
• You feel that the technical resource is best fit to provide these services since they are the ones developing the system.
• There are no identified business owners who are willing to provide training and onboarding support.

For those Universities who say NO:

• You are strapped for resources but you realize that your technical resource really needs to focus on the technical aspects (including Maintenance and New Feature Requests) rather than leading training and onboarding support.
• You have customers who are more knowledgeable on the “hows” and “whys” of how to use the system to support best practices and business processes.

The key to this consideration is thinking along the lines of a collaborative support model that includes both the technical side and the business side to support continued maintenance, new feature requests, and training and onboarding support. After all, Salesforce is a joint effort and there are many things to be learned from both sides before, during, and after implementation.

4 Buy Considerations

The Higher Education Advisory Council’s Build vs. Buy sub-committee has pooled their resources in order to provide 4 common considerations for Universities to use when considering a Buy solution.

Consideration #1: Does your organization understand the problem or challenge it is facing?

When Graduate Recruiters started using Salesforce for Lead generation at Texas A&M University-Commerce, everything was moving along quite nicely! That is until we completed Phase II of our pilot: SIS integration. The first problem we ran into was with the Lead Conversion process. Once a Lead is converted a Contact is created including an Account and Opportunity. (This is standard Salesforce functionality.) However, with the SIS integration, when a Lead was converted through the lead conversion process we would have 2 Contacts in the system: one created from the Lead conversion process and one created from the SIS import process.

The first challenge we faced with Standard Salesforce functionality was with mass email limitations. Standard Salesforce functionality only allows mass emails for up to 500 Leads per org. This is extremely problematic as all of our colleges have more than 500 Leads. One native Salesforce solution we looked at to overcome this obstacle was the use of Campaigns. However, we quickly ran into daily limits for workflow emails.

The key to this consideration is personal to me. As I am known as an out-of-the-box Admin (and I wear that title with a badge of honor!) I always recommend pushing standard functionality through what Admins call “Click-not-Code”. In essence, you push OOTB functionality as far as you can in order to identify weak points. By doing this you become well acclimated to your org, and you learn awesome ways of doing things that do not require any custom code or apps.

Consideration #2: Is your organization prepared to adhere to processes and parameters of the product?

Most Universities are under a time crunch to get things done. CRM implementations are not immune to this reality. Due to the nature of Higher Ed, there isn’t always time to hammer through all the minute details before making a purchasing decision – especially if it’s a base year. That being said, it is imperative that a University understand the importance of being able to adhere to out-of-the-box processes and parameters of the solution being procured. Sometimes this happens when a team is working on a vendor comparison sheet (i.e. My CRM does this – can your CRM do that?) or by speaking with other Universities using the same solution.

As an example: Say your focus is on the Recruitment funnel. You may need your solution to be able to capture Lead information whether it is coming from a web inquiry form or via import from a paper form filled out at an event. You then need a way to identify a hot lead vs. cold lead by assigning a score based on certain criteria. You then need automated processes in place that takes your leads and does something with them such as send email communications. You then need to be able to report on those things that are happening to your Leads.

And then sometimes there are surprises that weren’t anticipated at all. For example: Say you have been capturing not only Lead data in your Salesforce org but you have also been capturing student data using standard Salesforce functionality as well as custom object development surrounding things like Curricula, Degrees, and Registrations via your SIS integration. After speaking with a vendor who sells the first part of the student funnel (Recruitment), you quickly realize that your custom Salesforce org has organically grown to cover not only Recruitment but Retention as well. The question you have to ask yourself is how will you and your organization respond to this dilemma? Will you build out those custom objects that sit outside of the scope of the Recruitment piece? Will your users agree to the change in scope that could possibly delay the end date of your project?

The key to this consideration is clearly outlining expectations and requirements from all parties involved. Just because you run into a dilemma doesn’t mean that there isn’t another way to solve the issue. Get creative! Get collaborative! And get going!

Consideration #3: Has your organization established support resources/teams for maintenance and onboarding/training?

As with Build’s Consideration #4 – the same approach applies here.

Consideration #4: Data model synchronization and integration

Data model synchronization and integration really applies to both the Build and Buy discussion – there is no way of getting around this. When Texas A&M University-Commerce first started using Salesforce (Phase I) we didn’t have any apps or integrations. This was because we were simply recreating fields to match what was being captured in our Recruiter’s spreadsheets. However, Phase II integrated our SIS so we had to consider synchronization and integration.

Below are some considerations that we took into account regarding the Integration of our SIS:

• Integration with an ETL tool
• Data file generation from our SIS
• Scheduler to generate those files and store them somewhere
• Location in which to securely store those files
• How often the updates/upserts would take place
• Who to alert if there was an ETL error

Another consideration came from our experience with using an existing University web-form to collect Inquiry information.

• Integration with the online form
• What new fields needed to be created in Salesforce
• What mapping needed to be done on the web-form
• Which service account to use for the integration
• The process to follow if I needed a new value added to the web-form menus

The key to this consideration is identification of all data-points that will need to be fed into Salesforce. And if your plan is to have bidirectional movement of data between Salesforce and other systems (i.e. Housing, Orientation, Scholarships, etc.) you will need to understand the architecture of those other systems in order to create the necessary mapping.

---

As you can see there are many considerations to take into account when it comes to the Build vs. Buy discussion in Higher Ed. It is my hope, as well as the Build vs. Buy subcommittees’ that the 8 considerations mentioned above will help you and your University continue to make the most informed decisions possible in your Salesforce journey.