Find out how this innovative Financial Services company drives success by using Salesforce Community

Webinar presenting Forwardline’s migration from manual paper-based loan processing to a fully automated online application built on Salesforce Community Cloud with partner Magnet360. Forwardline (founded ~2003) moved from a 7-day manual funding process to under 10 minutes on average (often 5–6 minutes) by exposing an online application (OLA) that integrates natively with Sales Cloud, leverages credit-report APIs, Visualforce/JS for UI and browser-level third-party calls, and supports multiple guarantors and document uploads. Key outcomes: tripled application throughput without adding staff, semi-automation earlier reduced time to ~3 days, implementation required extensive requirements (≈180–200 pages) and took about nine months. Magnet360 described architecture patterns (SSO/identity, responsive UI, mobile icon approach, integration strategies) and shared similar community use-cases (Starbucks, Honeywell, Entrust Data Card, AgStar, Medtronic).
Questions this video answers
October 21, 2015.
About 2003.
About 7 days.
About 3 days.
Less than 10 minutes on average (often 5–6 minutes).
Chapters
Hello everyone. Thank you for joining us. Today we are presenting the Forward Line shares how they triple loan applications with Community Cloud. I'm Lisa Henderson, senior director of Community Cloud at Salesforce. We have an amazing customer story in Forwardline and one of our top partners, Magnet360, also online, will be presenting how they helped Forwardline and integrate Community into their overall business strategy. Before we get started, I wanted to call your attention to a couple of things. First, we will be taking questions as part of this webinar. There is an ask a question button in the upper left hand corner of your screen. That is a terrific way to interact with us. And again, I will be moderating and presenting your questions at the end of the webinar. We'll also ask you to rate the webinar, which I'll talk about as we close the webinar out. So let's go ahead and get started with our Safe harbor agreement. We want to remind you that everything you hear in this webinar, if it is forward looking, we ask that you not make purchase or buy decisions based on Forward looking, but what we actually offer as part of our services currently. So with that, I'd like to introduce the team from Forwardline. We have with us Michael and Steve, who represent forwardline in a marketing and technical capacity. And then as we move through the presentation, you'll be hearing from magnet360. Okay guys, take it away.
Thank you very much. It's a pleasure to be here today. Just a little bit of high level about Ford Lyne as it relates to the information we'll be providing you. We're a provider of small business loans. It was founded in about 2003. We were the first to provide what's called a merchant loan or an alternative finance loan to small businesses whose number one problem is really access to capital to grow. We use a lot of technology to finance small businesses that are busy. Small business owners that need to work quickly and need to have fast access to capital. Our business process now revolves entirely around Salesforce and we'll get into that in a little bit greater detail later. But it wasn't always that way. When we were founded, everything was on paper. And two years ago when Steve and I took on this challenge, Steve liked to say, you couldn't shake a stick without hitting a manual process. Even so, we've enjoyed 20% growth year over year. And at the same time, though, our industry is growing at a much faster pace. So we had a problem we needed to solve. We needed to develop operational efficiencies in Order to really grow and meet the 8 million customers that we could potentially serve. Most customers are the classic Main street business brick and mortar business owners you'd see in any Main street in the United States. Restaurants, salons, spas, professionals, online merchants and franchises. And as I mentioned earlier, they're very, very busy. We need to engage with them quickly, as few times in the buying cycle as possible and on their terms.
So nearly four years ago, our process was almost entirely manual. We had a paper application that we sent out in PDF form via email. The merchants would fill it out and fax it back to us. We'd actually print that out and then we would forward it around the office here. The data would get keyed in manually into Salesforce. In underwriting, credit reports were pulled manually and that data was entered into an Excel spreadsheet that would do our credit score calculations for us. And essentially our workflow was managed by stacks of manila folders that moved around the office. Two years ago, we made some significant improvements. We semi automated the process. We used some AppExchange apps to allow electronic form for our application to be populated directly into Salesforce. We used a different app, Exchange app, customized it significantly. That was our credit decision engine. It allowed us to pull the credit reports using API calls. It allowed us to store the credit reports in Salesforce as attachments, and it allowed us to then go do scoring of our credit applications by the press of a button within Salesforce. So it significantly improved basically the application flow and the underwriting process. Initially, it took us seven days four years ago, typically to go from application to funding. With the semi automated improvements, we reduced that to about three days from application submission to funding. But we needed some additional processes and actually go back to the previous slide for a second. Michael. At the beginning of 2014, we took on a mission to go to a fully automated application process. We needed to do that because we had to compete on speed in the marketplace. We needed to be scalable because we expected significant growth. It needed to be easy to use, simple for our customers. It absolutely had to integrate with Salesforce. It needed to be responsive in design so that it would work on mobile devices. And so we looked at possible solutions and came up with three options. The first was using an out of the box solution. There are several off the shelf products out there that could have been customized for our use. This was actually our CEO's first choice. As we started to explore this. It typically involves significant licensing costs. It would involve customization of the integration with Salesforce and the upgrade pass for it over time would be difficult at best. Second choice we looked at was just a complete custom build that was actually my favorite initially in this process. It also provided significant upgrade challenges. All of that would be controlled by our third party developers on that thing. It becomes an issue with all of the different browser versions that are out there and keeping up with all of that. And then there are questions about scalability and who's hosting it and how all that was going to work. So we got to talking with Salesforce and realized that there's this Communities cloud out there which we hadn't really considered for this type of an application. But working with Salesforce, they put us in touch with Magnet360 and we realized that this was going to be a real viable alternative for us. It allowed for faster development, it allowed for less expensive development. It provided native integration with Salesforce. The upgrade path Salesforce provides for us, we don't have to worry about that. And it's literally infinitely scalable.
So we built a requirements document, nearly.
200 pages and we sent that out to seven different vendors. We got all different kinds of proposals back. We ended up choosing to go with Community Cloud and Magna360.
Essentially by choosing an engagement solution like Community Cloud that's tied directly into our Sales Cloud instance. Salesforce is doing all of the heavy lifting so we don't have to have some custom website with a custom database back in to do the work. The OLA, or the online application that is essentially created as a part of our Community Cloud is now allowing our customers to engage directly with our Salesforce instance, get an instant decision and essentially do that in a self service way way without having to engage one of our sales folks. It allows them to do it at their own time, at their own pace, and engage with us and with our Salesforce instance in a whole new way. And here is the result. What took seven days three years ago now takes less than 10 minutes on average. Now we actually see our customers creating a login, engaging with the community's platform, providing some information and oftentimes just verifying information. Because we're able to leverage data that already exists in Salesforce and getting to that application decision within five to six minutes. It's a huge change for us in the way that we can interact with our customers. And because it all builds within our Salesforce Community Cloud, it's eminently scalable. We're now able to compete with our lenders and pace on speed. And that is essentially how we've been able to triple the application throughput from when we started this program, the way it's tripled is twofold. First and foremost, our customers now engage deeper because they can self service up to the point of that decision where they couldn't do so before. And second of all, we've been able to now increase our marketing spend because we're no longer bootstrapped by our headcount. We've essentially tripled our application volume without having to hire one single additional person. And we have a lot of work that we want to do. We've now realized the potential of Community Cloud to engage with our customers.
So the first thing we want to do and actually we've now implemented that is the renewal flow is now going through our online application or ola. We have a very high renewal rate here at Forwardline. We get a customer on board, they like how we operate, they like what they're seeing, and they come back for additional loans months or even years later. So the renewal process is a very simplified application process. We already have all of their information, we don't need very much more. All we really need to do is validate their information and go run an up to date credit score for them. We want to be able to interact with our users a little bit and help them through this process some more. So we're going to implement some chat, we're going to use tools like join me and whatnot to help our merchants go through that application process. The documentation requirements for our loans are a bit problematic at times. We need to get some copies of bank statements, we need to get driver's license, those sorts of things. Currently we're allowing the merchants to upload those and attach them to Salesforce, but we want to do a better job of managing that and tracking that information for them. And then we want to more fully automate our loan documentation, origination and completion. We're currently using an E signature app for that. But we want to get to the point where basically when they complete the application, you can basically go through our underwriting review and hit a button and have it all merged and sent out to the merchant for their approval, which will shorten the funding time even more.
And ultimately we work very hard on the marketing side to create resources, content, blogs, articles and infographics and other tools that our customers, our prospects and potential clients engage with every day. We really would like to bring that content into the community itself and surround the application with lots of viable content that both nurtures and helps fast track the sales process, but really informs our customers and allows them to coalesce around that content and interact with each other in a new way.
So I'd like to introduce Mike Peel from Magnet360 who I worked very closely with through the full development process and was integral in getting this online application built and working for us. Mike, it's all yours.
Thank you Steve. So this is Mike Peel from Magna 360 Solution Architect and also a director for our Sales assistant Estimating practice nationwide. I had about 15 years of experience inside of the financial services industry explicitly 13 of those have been on the client side in large enterprise IT primarily at annuity carriers. We're going to dive into this. I've got four slides around magnet 360 and then the last slide is kind of a broadening of the topic around communities and I'll touch on a handful of client success stories when we get to that slide. Magnet360 is a unique partner. We've been in the Salesforce ecosystem for over 10 years in Salesforce lifespan that's an eternity. We're a Platinum partner. That means that we've got the top recognition or level there and so we are a managed partner. So Salesforce has has a resource that sits on our board of directors and really observes what's going on with the company as a whole. We are a multi cloud solution, so most of the solutions that we do focus on more than one Salesforce cloud. So Forwardline is a good example. The vast majority of that project was community cloud, but there were a handful of changes that were required back in the sales cloud implementation as well as the two tools are pre integrated. We've got over 3,000 Salesforce implementations. I mentioned earlier about our special relationship with Salesforce being a Platinum Partner, but they're also a strategic investor in Magnet360. They provided or participated in two rounds of venture capital throughout our history as a company. We are a lead partner for Communities marketing automation and when I say that there's some really solid backing behind that. Case in point, our CTO Eric Schiel is invited by Gartner as the expert earlier this year to talk about Salesforce and their Communities platform. He was the only resource that was invited to have that investor discussion across all partners. Across Salesforce itself. Eric was the only resource that was pulled into that conversation. On the marketing automation side, we've got an active client in the Twin Cities area which Adam Postelnack, our marketing automation practice lead, pioneered the use of both Pardot and Marketing Cloud together rather than an either or. Those two tools came into that account as a both and and really enabled that client to be able to tag their websites and bring that information back in as far as how the resources were interacting with the brand, bringing those back into sales cloud and then back out through marketing cloud to drive targeted on point messaging back out to those users. So rather than just interacting and being able to market to people based on their transactional history, so what sort of purchases and those sorts of things in this case they're able to include that. But coupled with if they're looking at other product lines as an example on the website now they can tailor those messages so it's more relevant. That is something that's changing how Marking Cloud and Pardot are going to market. We are one of eight marketing cloud managed partners and then our expertise is listed there. I'm not going to read through those. You can read those for yourself. So going to the next slide we have, this is kind of the standard NASCAR slide. Almost all implementation partners have these. The one thing that I will call out on this slide is all of these icons are clients that have done business with us in the last 90 days. So this is not a slide where we just accumulate brands over a period of time and they've not been an active client. All of these clients that are listed here have been active in the last 90 days. So this slide really gets into how we view or how we like to engage. So from a multi cloud solution standpoint, it starts with strategy. I'm going to see if the build functions here. All right, so I'll go back. So we like to start all engagements with strategy. Understand what your business objectives are. Having the forward line example is wonderful. So one of our core mantras is engagement for outcomes. And that's not Magnet360's outcomes, it's our clients outcomes. And so being able to complete a project and having this sort of business impact is exactly why we get up from bed and go to work every day. So starting with that strategy and then the core, because of how the Salesforce clouds are constructed, the core of the solutions is really that same common database that's all around your core audiences or your customers. So the relationship management component which really tracks back to sales and service cloud, kind of the core Salesforce implementation clouds. And then from there we branch out and we'll layer on branded app sites and communities. Apps are exactly what they sound like. Mobile applications built on the Salesforce platform. The communities product, which we heard from Forward Line, one customer example of that today Wave is also in that category. And then from there we go out to multichannel marketing. So Marketing, Cloud and Pardot. As we look at this build or these different circles here, there's a certain order that you can approach them in. We have some clients that will approach us and say, you know, we just want a transactional project and will interact with us more. As a vendor, our preference is to be treated as a partner and again start with strategy and and then create a roadmap and implement projects towards that roadmap. However, we do engage in various orders and varieties across the spectrum. Going to the next slide. So when we think about the community's product, in fact the community's product started back with the portals. So Salesforce had a product back in 2004 that they introduced that was really around portal capability, so allowing a customer or partner to log in and interact with their information that was stored inside of Salesforce. So we had started our engagement with that Solution back in 2004 and have had a number of success stories from then till now. A couple that I'll highlight here and we'll see some of these again on the next slide. But the Starbucks Ideas Portal. So if you've been in a Starbucks recently and you'll notice a number of things that have product innovations that have that are there. So things like the cake pop as a product that did not exist until this solution was put in place and Starbucks customers could start to create ideas, vote on ideas. Starbucks reacted to those ideas and made those changes. Having the calories listed behind every menu item, that was another idea that came from this ideas portal. The little green stick that they'll put inside the top of a a cup of coffee so that as you walk out of the store it doesn't spill on your hand and create burns. All of those things came from this ideas portal where they really started to listen to their customers. Also at that point in time, Starbucks had a dip in revenue for the first time. And so they engaged with us to say how can we become more responsive to our customers and make some changes in order to recover from that dip in revenue and really continue their growth, which they were very successful in doing. As we move through the process here, through the chart, we'll see Target on the next slide. That was an employee targeted solution. So really being able to have the employees of Target submit ideas back in and have HR in operations respond to those ideas. The Honeywell community, I can speak to that for a period of time here. So this was something that was up on stage for Dreamforce and we got a Service Cloud Award for Innovation Award I think two years ago, effectively this is their connected thermostat. So in their marketplace, what they had was a scenario of third party service people. If I was in the Los Angeles area as an example, I may have a territory and my job is I'm an H VAC repair company. And so I would contract with Honeywell in order to fix H VAC systems in offices and homes. And in this case, what we were able to do partnering with them is the connected thermostat play from a connected devices standpoint. So taking that information from the thermostat back into a large data repository and then building a front end in salesforce communities for those dealers to interact with the data from the H VAC systems. So what it allowed Honeywell to do again from a business outcome standpoint is instead of having those third party dealers wait until something broke and having a homeowner call them and say something's going wrong. With my H VAC system, furnace, air conditioning, those sorts of things, they're able to start to be notified proactively. So in the case of a scenario where maybe I haven't changed my furnace filter in a couple of years, hopefully that doesn't happen. It's a fire risk. But as homeowners, sometimes that occurs. If that were to happen, there's airflow statistics that go from the furnace into the thermostat and then can be detected back in their data repository. That sort of event would then be published back into the community. So the dealer in that territory would then get a proactive notification that something may be going wrong with that furnace system. So from there they have the ability to engage the homeowners directly. And oftentimes they're able to walk them through a fix without having to schedule the appointment. They'll give them a two hour window and try to arrive during that time frame. And those sorts of things at the end of the day, every time they don't roll a truck or they don't send a truck out to a house, it saves the dealer money. So from a go to market standpoint, it also then allowed for Honeywell to charge their dealer network a fee for that service. So it gave them another revenue stream. So very impactful. And then as we move forward, you can see forward line, you heard from that very successful customer on their example, there were 33 custom VisualForce pages that were implemented for that. A large amount of rules for the underwriting decision, logic around the loan, integration with third party background checks, those sorts of things. In this case, directly from the ui Rather than from the back end that was to engineer around some governor limits. And then the electronic signature component as well. There's a significant amount of custom routing. So if you think about all of the things that can go wrong in a loan application, almost every one of those has its own error code that when the user would log out and log back in as an example, it would potentially take them to a different page. So there's a lot of complexity in that portion of the solution as well. And then as we move into present, there's a litany of things there that we've been working on. So this slide, as we think about communities and you may have picked up on this on the last slide to a certain extent, but we don't think of communities as just one solution. Actually think of the community engagements that we have across this sort of a spectrum where we've got customer, partner and employee going across the top. So who's the audience that's interacting with the community and then what's the type? Innovation, Self service and engagement. There's some other variations here. You could have a scenario where it's actually multiple. We could have a scenario where we want to. We'd have a client and we've seen these sorts of requests come in where they want to have a client and partner portal and be able to allow collaboration between the customer and in a dealer scenario, the third party dealer, but then also have home office influence as well into that conversation. So we've seen those where it's a hybrid between these. The other thing that we've seen more and more frequently is the need to put a mobile component on the front of the community. So how do you build that interaction? Logic once, build the transaction once, but expose it both through a community that could be viewed through a browser and through a true mobile experience. And we've got spectrums across the mobile requirements as well, which I'll talk about here shortly as it relates to a community. But I'll just pick out a couple. So you heard me talk about the Starbucks site up in the upper left hand corner. So very much targeted at their end, customers and innovation, really looking for additional ideas to drive their business forward. I touched on that. A slide or so. Entrust Data Card. So partner self service. So in this case Entrust Data Card, if you're not familiar with their business, they sell security solutions. So as a result of a merger between two companies, one portion of the company had a product line that would produce badges for employees. So you think most of you may have those on your hip right now or in a lanyard, there's a good chance that that product is actually originated by by NTrust data card. The other side of the business deals with they make security software for servers for enterprises. So in this case what we ended up doing was leveraging the Salesforce data set to allow for a customer, in this case a partner, a B2B partner, to be able to log into the community, see what products they've purchased, access the technical specifications and FAQ or frequently asked questions around just the products that they purchased. They also have the ability to download additional security patches for the software that they purchased. So from an NTrust data card standpoint, they had uploaded into the community or into Salesforce all of the patches that exist for their software and all of the health information, all the technical specifications. But because they produce many, many of those SKUs from a customer standpoint, the customer really wants to see what's relevant to them. So being able to leverage the CRM data that's already in sales cloud around the customers and what they purchased and who's at those companies to drive security as far as what feature set they can access. And for all of our authenticated communities there might be an exception, but with almost all of them, what we see is exactly that is one of the common threats, being able to leverage the accounts and the contacts in Sales Cloud to drive security, access to data and function inside of a community. From a deployment or implementation standpoint, what that means is that all of the time and effort that would be spent integrating those solutions together or replicating that data into a more traditional web platform falls out of the implementation. So most of the time it leads to much faster implementation and much lower cost to business value. There's two others I'll talk about here. AgStar is an example. So this is another community that we did in this case for their customers. Agstar, if you're not familiar with them, they're a financial services firm focusing on the agricultural market in Minneapolis, Minnesota and part part of Wisconsin. The territories are mandated by the farm bill that was set up back right around the Depression era. So they've got a geographical territory that they really can't move in and out of. But their business model is they had a number of web solutions that existed and they were disconnected and disparate. And so what they asked for us to do is come in and allow their sales resources to that are out in the field to have access to all of those different systems on an iPad and so that they could see everything from mobile banking transactions to sales collateral for their products based on their different product lines, they had different transactional systems. Their products will allow a farmer to do everything from get a loan to purchase more land to a combine. In some cases, they also have mortgage products that can be purchased by people that live in an agricultural area, but aren't involved with the agricultural industry. So they have a broad spectrum of products. And so they needed a way to bring all that together and provide a unified customer experience. So the solution that we did there brought those things together, applied that security layer based on the accounts and contacts, as I mentioned, very similar to Entrust Data Card. But the big difference here that I want to call out is the mobile requirements. So AgStar asked for how can we get this to look and feel like a mobile app? And we said, well, let's talk about that a little bit more and understand what your mobile requirements are. And in this case, you think about mobility. Kind of the first threshold is I want to be able to see it on a phone or on an iPad or a tablet, but I want it to be a tile or an icon on the desktop, for lack of a better term. So that's kind of at one extreme. And on the other side, where we get into true mobile requirements are things like geolocation, sms, push messaging, access to the camera, those sorts of things. And for Eggstar, what they were really looking for was that at the very beginning, just the icon on the device itself. So what we ended up doing was building a responsive community. And the first time someone launches the community, it gives them the option download directly from that site, download the icon, and from there on out, they can touch that icon and it will launch them into the community. The reason why that's important for a business standpoint is that in the event that we had tried to build them a true mobile app, rather than taking the approach that we did, it would have required different languages to be brought in, different skill sets to be applied. We'd have to build some of that functionality in multiple places. But also the application itself would have to go through the Google Play Store and the App Store for Apple, by taking the approach that we did, it didn't have to go through that, through those approval stores, which also gives them additional velocity if they want to change it, so they're not constrained by the security reviews and the software reviews that each of those marketplaces will do. So that's one aspect of how we look at understanding what the customer's need is and then matching the solution to where their need is across that spectrum. The last one that I'll talk about here is Medtronic customer engagement. So this one is interesting. So as we know, Medtronic produces medical devices across a very broad spectrum. And in this case this is a completely different play. So Medtronic also has a grant program where they largely view their customer outcome as granting additional life to their patients. So their grant program allows for a patient to, after they've had a medical device implanted, a pacemaker, or the other products that they have, they can write up a grant application that will talk about what they're going to do with their extra years and make a request into that grant program to get some funding to go live their dream. So for people that have had that sort of experience, it's life altering, right? I mean, these people that need these sorts of products, oftentimes it's very unexpected and they're forced to make some very hard choices that they've not had to make in the past. And so for them to be able to reach out and secure some grant money is a big deal. They can go out and oftentimes they'll pivot their lives. They'll find meaning and pivot and go in a different direction. And so what this community allowed for was the intake of that application process for the grant. But then it also did would publish what success stories people are doing as they're going through that grant process. So after they get granted the money, what are they doing with their extra lives or the extra years in their life? So in this case, it's very much a customer engagement play. There is no revenue source, there's no connection into the actual products that they, they have. So it's different. That one is unique from all of the other examples that are up here. So with that, hopefully today you've heard a bit about how Forwardline has increased their application flow. We've talked about Magnet360, hopefully relatively briefly and also broaden the spectrum of how the community cloud is positioned. It's not just around a social aspect into Salesforce. It's not just around one type of implementation. It can actually be used across a whole spectrum of business problems. So I will click to the next slide here and we'll open it up for questions.
Hi, thank you so much. We have a couple of questions that have come in. The first question I'm going to pose to Both forwardline and magnet360. The question is we have heavy underwriting guidelines with many borrowers on one loan. We currently use a system that can Import information from Salesforce. Are you suggesting or recommending we move all of our underwriting into Salesforce? And specifically how did Forwardline handle that?
So our loan process also frequently has more than one guarantor associated with a loan and that structure was built in with the online application in the custom object structure. So we have multiple guarantor records associated with an individual application record. Our credit scoring algorithm also handles multiple guarantors. We pull credit on each one of those and various attributes from those credit reports go into the overall scoring algorithm.
And it works very well for us because all of the information is thereby contained in one place with the types of profile and user level security that allows that safeguards access to that critical personal data. With the added benefit of having the high level of security overall in Salesforce, much, much more of a comfort knowing that that data is so secure versus in another system. We did this through an app, Exchange app. But we're very interested in looking at the financial cloud, which we learned a lot about in the most recent Dreamforce presentation. It looks like the type of tool that would be a very viable solution for bringing underwriting data into the cloud.
Terrific. A couple of more questions and this is again for both forward lines. Go ahead.
This is Mike from Magna360. I'd like to jump in and give you my perspective on this one. Certainly as we look across the ecosystem of our clients, my first question back to this question would be let's talk about the complexity of your products in the case for a very complex underwriting process, something from like a life insurance example, something in that scenario, say, you know what, there are underwriting tools that exist. There's probably a good reason to select one of those and leverage Salesforce to gather the information, be that engagement layer, but still allow for the underwriting rules of that level of complexity to exist in that other system. In this example that was provided here today with Forward Line, the complexity of the underwriting rules to that level did not exist. Are they complex? Absolutely, they are. However, we didn't have things that we'd see in some of those other product lines, like looking out to do a forecast of where your premium would be over, say 30 years. Those sorts of requirements that exist in some other products and some states for that matter, with special regulations in New York, those sorts of things. If we were dealing with that sort of an issue, we probably would have made a different recommendation. But for the products that we had here, we were able to implement those rules with those external callouts with a couple thousand lines of Apex code.
Very good. A couple of other questions I'm going to pose both to Forward line and to magnet360 for forward line. As you were heading into this process, what was some of the pre planning and early questions that you asked? To a brief magnet360, but also to make sure you addressed your specific business needs.
We went a little bit overboard actually in the preplanning. I think we spent months talking through every detail of our application process, trying to make sure that this online application would handle all of the different scenarios that we would be dealing with. Whether it was a new customer with a new funding, did a lead already exist in the system, was an organic lead coming in, did they already have a loan with us, did the account and contact information already exist? And we had to make all of that seamless to the customer. So we did a lot of preplanning to figure out what all of those scenarios are and how we wanted the application to handle it. The result was a document that was 180 some pages long that I'm sure magnet 360 looked at and rolled their eyes a little bit. There was way more information in there than there probably needed to be. But we wanted to be that thorough in, in thinking the whole process through.
And Magnet in the receiving end of that information, how did you approach and think about the design and the community cloud solution in particular and meeting the needs of Forward Line? So on your end, what was the planning and the thought process?
So from our standpoint, that is what Steve described did happen and across our customer base, it's a little unusual to have that much forethought, really be in place before coming in and engaging on the project. So from that standpoint, like I said, a little unusual, good in a lot of ways because that means that Forward Line had thought through the entire process and we didn't have many situations where we'd have a question and. And it ended up resulting in an internal business conversation for weeks before we'd get an answer back. So from that standpoint, it was very good. So we follow an agile process. And so what that meant in this case is we would take that information or that document, try to decompose it into user stories and put it into our project management tool, jira. And then from there we would associate tasks to each story. Some of the content as it was, as it was built, as you can imagine, wouldn't necessarily translate directly. And so we had to have some conversations about how to repackage and reframe and pivot the process around to Allow for that. Good example of that would be all of those routing decisions. As I had mentioned earlier, there's a lot of complexity in that area. I think there were two separate 10 to 12 page documents, depending on if you were the primary guarantor or if you were one of the additional guarantors. There was also some differences between pre consent and post consent or pre signature and post signature. So being able to take that as an example, we said let's just, instead of expending the effort and the time and ultimately the client's money to transpose that into specific set of user stories or requirements, we said let's just create one user story and attach the document. Again, it's about trying to make sure that we're being laser focused on providing value and not being strictly driven to the process or adhering to the process. What I will say about communities in general, a couple things. One is communities, especially if they're going to be customer or partner facing almost across the board, we get a requirement that says something to the effect of the look and feel of the community, has to match my public brand standards. In this case, having a large amount of content going in. We had some of the wireframes already done and Forwardline was able to provide some of those and in most cases we could take them and implement them directly. I think there were maybe a scenario or two where we had to make a couple of tweaks based on what the solution could do as far as very minor usability issues, but there were no major constraints on that side. But different from a sales or service cloud implementation, we'd be talking about what sort of fields we need and business process and those sorts of things. We had to have those conversations with this project. Yes, but we also had to think about it more in terms of like a custom website design, so establishing what those wireframes are, what a site map would look like and then moving forward. So it's a layer of work that generally speaking is across the salesforce spectrum ends up being unique to communities. Cloud that doesn't necessarily exist with some of the core solutions.
Okay, a couple of last questions for Forwardline. First, how long did it take you to implement? And then second, once you were ready to launch, what were some of the key learnings and tips to get your customer base on board and using the process?
So the full process took.
About nine.
Months to work through all the development and implementation. And that, you know, we were not constrained. We didn't have a hard deadline, so we took longer than we needed to because we wanted to make sure that when we launched this thing it was right. The last thing we wanted to have happen was for a customer facing piece of software to not work well. It just was not going to work for us in the long run. The hardest part of the implementation was really the adjustments that needed to be made in the internal business process in.
Adoption, driving adoption from the onset. In retrospect, we could have done a much better job of developing a communication strategy in of terms internally and fostering internal champions from the get go in order to better iron out the business processes and essentially help facilitate a cultural change within our company. There was a little bit of fear around this new giant automation tool that would significantly change the way that our own internal assets interact with Salesforce by nature of our customers being able to now interact with without them as a proxy. That being said, it took a little bit of extra time to get that level of engagement, but it didn't take long for particularly our sales team to realize that they were going to be able to serve more customers more quickly in a more customized and meaningful way. As a point of having this tool. And as soon as a few people had major successes in terms of increase in their volume and throughput and their high sales commission, you can bet the rest of the team got on board pretty quickly. That being said, I do recommend just as much as we spent time banging out requirements and wireframes from the get go, developing an adoption strategy will probably streamline your production rollout.
Okay, and we just received one last question. Can you discuss the advantages of using communities in the development and implementation of the user experience? What kind of architectural decisions were attended with that?
Well, one of the key elements from our point of view was for instance with the user authentication process, the login process we had, and we spent a month probably going through exactly how we wanted that process to work, thinking that we were going to have a complete custom application. And so we spent a month. We probably had 75 pages of that initial document that was related to user login and authentication. When we went decided to go with the communities, that was all there for us. We're using Salesforce native login functionality and user authentication and a proven user positive.
User experience to go with it.
So we didn't have that development effort to go through. And so that definitely shortened our development time and our testing time.
I'm sure Mike has a lot to.
Say about this as well.
Yeah. So I'll try to keep this specific to the forward line project. So absolutely the single sign on approach Leveraging Salesforce community, which includes the identity provider Salesforce acting as an identity provider is one large ad and having that. So if you're not familiar with that, any contact inside of the system that is flagged, that is also in the community, the user record that gets created is associated to that contact. So that's how the you think about from a data model standpoint, that's how the objects are hooked together. So that was one in this case with that the background checks. So I mentioned this kind of in passing, but there are some governor limits that exist in inside of the system. And so in this case in part to address those or to not have additional web calls or API calls hit that particular governor limit. The integration out was done from the browser level. So I apologize to anybody that's not technical that's on the call because this is down in the weeds a long, long way. But that was done from JavaScript. So that would allow for us to reach out, make that call to the third party service, get the results back and not hit that governor limit. In this case, as I'm sure you're imagining, there's some latency that's involved. It would be a synchronous call. The browser has to stay open while that's occurring. And based on the requirements and whatnot and working through that particular design issue that was deemed to be acceptable. Other things that happened here. I'll go back to more of the UI Explicitly the UI in this case, you guys have all probably seen Sales and Service Cloud. The UI for Forward line looks nothing like Salesforce. In fact, with the exception of maybe one screen that was remaining around, change your password or something of that nature. Salesforce, that word is not used anywhere on any of the UIs or the emails that come out of the system. In this case it was entirely skinned to match the public web standards. There's some level of URL integration at that layer from the website in. There's also integration from the Marketing automation system into Salesforce as well. So there's integration there. I think there was also some components around Google Analytics, some data variables from that so that we could track the lead source that was also coming in on the URL as a parameter going into the login page. So that was a set of things that we did. Largely the UI in this case is visual force based CSS JavaScript. The UI itself is responsive, so it means it will resize depending on if you're looking at it on a phone or a laptop or a tablet. But there's also some reflexive questioning in the solution. So as an example if you say that you are a franchise as a yes or no question, if you hit yes on the screen directly underneath there it will extend and ask the user another question so that without going back to the server and refreshing. So all of those things are user, at least that last set are things that are user interface based architectural solutions that we're able to bring in with communities.
I think the other key element in the communities is the data integration. The fact that all the data is stored within Salesforce objects and therefore it's right there for anybody to view who has permissions and it makes it much more easily reportable.
Okay, I want to thank everyone for joining us today and a special thank you to our presenters today. I want to remind you that you can rate this webinar and we always look forward to your feedback. Thank you for joining us and have a terrific day.










