In our second episode of Serious Insights for Salesforce Admins, host and Salesforce MVP Kristi Campbell welcomes Emilie Jensen to the show.
Howdy. The Cirrus Insight team is back with another edition of Serious Insights, our new video series that explores the questions and challenges facing today’s Salesforce Administrators. This week’s episode deals with a debate we’re sure people reading this are familiar with: Build vs. Buy. As in, do you build the solution your organization needs, or do you purchase a solution from a resource like the App Exchange?
The thing is… This topic is already extensively covered throughout the entire Salesforce media ecosystem. And there are only so many ways you can answer the Build vs. Buy question with, “Well, it depends.”
Don’t worry. We’re going to say that same thing here too, but we’re going to give you a framework to help figure things out for yourself. And! We’re also going to link you to a few great resources at the bottom of this blog post that goes into further detail exploring the different factors that might influence your decision.
So there’s not much value in us regurgitating a blog post here about the pros and cons of building vs. buying (or vice versa) when no one can answer that question except for you and your team.
What we are going to do instead is…
Think Like a Journalist
Why? Because the framework used by a journalist is exactly what we think Admins should adhere to in making their build vs. buy decision. And for those of you just joining us, here’s what we mean by “Think like a journalist”: When constructing a story for the purposes of reporting to other humans, you need to be concise with your words and specific about who you’re talking about, what those people are doing, where are they doing it, when they are going to do it (if they haven’t done so already), and how they’re going to do it.
You might have seen this before simplified as Who, What, Where, When, Why, and How. Once you know the answers to those questions, you edit down what you have into a clear narrative that anyone can follow.
Why?
This one is a bit of a twofer. In getting to the heart of a build vs. buy debate, you have to first ask why you’re having the discussion at all as an organization.
Is this something you absolutely need to do, or is it something someone wants to do? There’s a huge gap between need and want, right? And you need to cut to the heart of what it is you’re doing and why you’re doing it.
Otherwise, nothing else you do is really going to matter. You may go for one solution, let’s say build, only to find that this solution doesn’t address the why behind why you had to make a decision in the first place. Now people are angry. The boss is angry and they’re throwing stuffed unicorn dolls at you. That’s not a world you want to live in.
Think of this as the Internal Why. “Why do people in my organization want us to make this decision?” You can’t get all your stakeholders on board (the WHO) without understanding the Internal Why. So on your first data-gathering mission, that’s what a reporter would look into first.
Then you have the External Why. This is the one most people are familiar with. Especially because it’s been popularized in the tech and marketing world as “Solving for X”. Or, “My product solves X, X, and X problems for the customer.” So you’re no longer looking inward at why the people IN the organization are making this decision, you’re looking outward at what this change would mean for customers and why you’re doing it for them.
If you learn the internal why of “Why is my organization needing to make this decision”, then understanding the External Why can often flow from that. “The boss wants us to make this change (Internal Why) because we’re not blah blah blah. And in order to do more blah blah blah, we need to implement X. (External why)”
- The boss wants to make this change. -->
- The change would help our customers buy more stuff
There’s an easy way to remember this. In the military, there’s a saying that when the General makes a suggestion, you should consider it an order. So if that’s true, the internal why is because the general is making the suggestion, and the external why is the suggestion itself.
Who?
That was complicated, right? Well, don’t worry. It gets easier from here. That’s because the who is exactly what you think it is: Who are the stakeholders involved with this build vs. buy discussion? Who is going to do the installation? Who is going to secure the data? Who is going to take care of upgrading and patching the software over time? Who is going to use this software? Think of it like this: If you take a huge rock, and you throw it into a pond, what happens to the water? There are all these ripples, right? Your decision to build vs. buy is the rock. Once you’ve made your decision and you throw the rock into the water, the ripples are all the different outcomes that come from making your decision. And the question of Who cuts right to who is going to act, or address, those ripples from your decision between now and into the future?
In the journalism world, the Who can also be sources for your story. So there’s the world of the story you’re telling, and all of the WHOs involved there. In this case, the people who are going to update the internal Confluence documents that hold your company’s knowledge base as an example. Since those people are going to need to put in some work if you build your own solution; and then need to explain to the people who may come into the company long after you’re gone to understand why you did what you did and how to use it.
But don’t forget!
You’ve also got the WHO who are helping you shape the story. So for a journalist, that’s the sources they go to in order to provide a larger perspective on things. If you’re doing a story on the president, the president is a Who. But also a Who is your source inside the White House who is passing information your way. And that WHO is just as important. So you need to know who all your stakeholders are in the build vs buy decision, but you also need to know who YOU are going to go to for help and advice on choosing, and then implementing, and then educating others, on your choice.
What?
Again. An easy one … Or, easier than figuring out the why. And probably less leg work than WHO, but you should not try to get through the Who thing until you’ve gathered a good list of people you can consult and discuss on the decision you want to make.
That means, this instance, the What is sort of like your junk drawer.
Anything that hasn’t been addressed so far, or by the other questions below, gets addressed with the what.
For example in the Build vs. Buy discussion, the what can be all the pros and cons of building and all the pros and cons of buying. What can also be all the questions you have like the cost behind buying something vs. the cost of building something. This could also include the cost of maintaining the thing you built (or bought) and educating others in the organization about how to use the thing you built.
So you can see how the junk draw fills up quickly. And that’s ok. You don’t want to get so crazy with gathering the data that it takes years to make a decision, but you do want to do a thorough job. (How you define thorough is, alas, also something that’ll depend on you and your organization.)
But here’s the trick to the What. The What is when you start smoothing out your data into a compelling narrative: “We are going to buy this software solution because this is what the CEO wants us to do and because the buy solution will save us money versus what we’re doing now. That money can then be reinvested into our customer service department.”
Think of it like this: You clean out your junk drawer every so often don’t you? Well. I mean, I hope you do. You do you, you know? But if you do clean your junk drawer out, what are you left with?
A clean, well-organized space where you understand what goes into it and why. And sure, is that drawer going to eventually get filled again with screwdrivers you have no idea how you came into possession of? Absolutely. That’s just human nature. But was the draw cleaned and organized long enough for you to make a clear decision, at that time, of what should and should not go in there? You bet!
Where & When?
I put Where and When together because all you really need to know is that specificity matters most in answering these two questions. When you’re telling a story to people, whether or not it’s fiction or nonfiction, people get invested more when you’re specific about how the world you’re telling them about operates. That’s true for journalism as well, and why you often hear stories that tell you what color the sky is or what color overalls someone is wearing while they wait in line at the Subway inside the Walmart. (See what I did there? Subway INSIDE of a Walmart creates a better visual picture because of its specificity than just “a Subway”. Especially because if you’re a New Yorker, you may immediately think of the subway with the trains as opposed to the subway with the terrible food. We’re kidding. About that last part. Every Subway franchise is different, just like every organization is different within a well defined ecosystem.
The point here is that when it comes to build vs buy, the specificity of what either solution is going to do, and not do, is probably what’s going to determine the decision after the other stuff we’ve discussed. That means, you have to be really specific as to what you would be getting out of a piece of software you purchased, who is installing it, how, where are they installing it, and when it will be installed. The details matter. So the more details that you have about the options you’re investigating, the better it is for others to understand clearly why you made the decision that you did.
By the way: If you think that having all the details is going to make your decisions bullet proof or unquestioned, think again. There’s always going to be someone that wants to lob tomatoes at you, no matter who you are or where you go in life. So you can’t make this decision of build vs. buy out of fear. You have to do it with the best possible information you can muster and then move on with our life once you’ve committed to a course of action.
How?
This is the fun one. Or about as much “fun” as actual work can be. Which, for some people? A lot of fun. For others? Mildly entertaining at best. The How addresses any and all of the mechanics not discussed thus far. So for example if you’re telling me a story about an escaped Zebra from the Cincinnati Zoo, I’m absolutely going to want to know how this Zebra escaped and what he or she was doing in Ohio in the first place.
This is true for build vs. buy as well. You’ve gathered up all your information from asking good questions, and you got yourself some detailed and thorough answers.
Now you need to explain yourself, your decision, and how it will impact all of the WHOs that you talked to.
And if you can’t thoroughly, and simply, explain all that, you need to go back to the drawing board and start again. Simplifying the message again and again until your average five-year-old can understand and grasp why you’re doing what you’re doing and how this solution addresses the problem you’re trying to solve and who is going to take action / who is going to be impacted by your choice of solution.
Listen to part two here.
Serious Insights for Admins, Episode 2: Build Vs. Buy (Part 1)
(The following transcript has been lightly edited for clarity and readability.)
Kristi Campbell: Hello and welcome to Cirrus Insights. My name is Kristi Campbell and I'll be your host. I am the Adminitect at Cirrus Insight. And joining me today is Emilie Jensen, who is the director of sales operations at Infrascale.
Also, I know [whom] wears many hats and describes herself as being known for empowering others, excellent attention to detail and her love of ambitious projects, which is a great segue into our topic today. So, hello, Emilie.
Emilie Jensen: Hello, Kristi.
Kristi Campbell: Thank you for joining us. If ever I do slip up and refer to you as Ekers, I think you will still reply.
Emilie Jensen: Yeah.
Kristi Campbell: Emily and I know each other from the Salesforce Discord Community. And she had made some comments about different projects along the way. And so, when we started talking about topics for the show, this one we wanted to talk about build versus buy.
So, you've got a new project coming up, and I think this, for any admin/architect, becomes the question, right? Do you want to build something? Or is there something you can buy? Combination of each? So, we wanted to talk through that a little bit. You maybe want to give some insight as to why all those hats you wear and or why I thought you might be a good person to talk to you about this one?
Emilie Jensen: (Laugh) So, do you want to hear about the hats or why the hats?
Kristi Campbell: Both. All.
Emilie Jensen: Okay. I wear a number of hats. I'm a co-admin for Salesforce. I also work on a number of integrations for different systems into Salesforce and with Salesforce. I primarily started with the sales team as a sales development rep about seven years ago, or “business development rep,” I'm sorry. And then kind of worked into sales ops and became an accidental admin at the same time. And in doing so, kind of started taking over more of the sales operations side of Salesforce administration for the company, whereas my co-admin took over more marketing operations.
In the last year, I moved into the finance department. And so, I've also started working on a lot of billing operations and also helping the co-admin with marketing operations. And now, we kind of just sort of like trade tasks. Whoever has the nearest skill set or the time
Kristi: The whole Rev Up cycle.
Emile: Yeah. Yeah. So that helps with that.
I still kind of focus more on sales operations in the business processes than he does. But I do wear more hats within the organization with four different departments than I used to, which is exciting. And I think it really is worthwhile for people who do have a lot of business systems and do have a lot of integrations into Salesforce to be aware of the different departments, business processes, and what their needs might be for Salesforce to fulfill on or these systems to fulfill on for the entire business.
I think that having a holistic approach is... good, very beneficial. And at least that's what we've seen over the last year of things shifting, and people moving around in the organization a little bit more. And it's exciting. I really, really enjoy working on so many different products in so many different departments because it informs each other.
Kristi Campbell: Yeah. Digging into all the problems and trying to make things better.
Emilie Jensen: Right...
Kristi Campbell: Go ahead.
Emilie Jensen: ...Yeah. Sales operations and billing operations, they go really hand in hand. Sales ops have to know how billing ops needs things so that they can process the opportunities that get booked. So that they can process the products that get sold. They need to understand fulfillment operations so that sales operations can support fulfillment operations and all of that. So that's always been helpful for my position.
Kristi Campbell: Yeah. And I think too that kind of ties into this conversation in terms of, really, before you can even approach a build or buy conversation, I think that the idea of asking why five times and really digging into those requirements and really understanding that business process is a key part of it. Because I think it's easy to hear one thing and be like, "Oh, I can build that," right? Or, "Oh, I just saw a demo jam with this app that can do that." And then to potentially get caught up in other features and other things, but really trying to understand the core of the problem you're trying to solve before you even start trying to solve it, which seems obvious … but isn't always the way to go.
Emilie Jensen: I know. Right. It seems really obvious, but I think having a strong approach is the hardest part. You can ask “whys” a lot. You can adopt different methodologies, but finding the right methodology that works for the people in your business and works for you. Either if as a Salesforce admin, as a Salesforce architect, as a Salesforce developer, that's going to be key to your success.
Kristi Campbell: Yeah, for sure. And I think part of it too is understanding what things are essential, like is only 100% fit acceptable for your solution? Or is there a good enough for now like, moving things forward kind of angle? There's one key need, but a lot of nice to haves that kind of what you were saying or does it make it easier for finance, even if maybe the salesperson isn't the one that cares about that feature on the front end.
Emilie Jensen: Yeah. That's a really good point. And that's such an interesting balance, right? You have different philosophies in leadership. And those philosophies and how they see the systems can really impact how the users leverage the systems, right? So, for example, at one point, we tried to make Salesforce the center of our system hub, everything went to Salesforce, Salesforce was kind of the final destination for the majority of the data. But that wasn't always true. We still had data that was living in different receptacles and different types of databases that were homegrown or otherwise.
And those other departments didn't necessarily want that data moving into Salesforce. Now, it was a decent philosophy. And I think it's a philosophy that a lot of other businesses utilize. But at the time that this philosophy was occurring, maybe three or four years ago, they weren't willing to invest in additional integrations or system updates to Salesforce in order to properly enable Salesforce to be the center of the data for the business, which it ultimately made it very difficult to do reporting, because finance would count on Salesforce being incredibly accurate for its billing operations and so on and so forth, or for due diligence rounds with financing.
So, that was an interesting place to be and that really is kind of where the whole build versus buy situation for me started, where I had to start leveraging Salesforce, leveraging standard or custom objects in really unique ways in order to fulfill certain business requirements, because they weren't willing to invest budget into new systems or into AppExchange products or add ons.
Kristi Campbell: I think it's interesting too to think about the budget… It feels like a straightforward thing, right? Like, do we have the budget to buy this tool that could solve? Is this magic thing that could solve all our problems? But also, what's the opportunity cost or really the salary-related costs of not doing that, right? Even if you have the resources of people who have the knowledge you need, what does their time cost to come up with workarounds? Or like you say, to do things manually or the tradeoff, I think, doesn't always get the credit that's due, right? For an alternative to buying something.
Emilie Jensen: Right. There's a lot of different resources in the question, right? There's time and resources. Does your admin have time to spec a new solution? Does your admin have time to research the variety of solutions that are out there for the business need? Does your admin have time to install it and then train users to use it? For me, the training of users was such a big part of the equation that a lot of the time, when I was considering, do I build it or do I buy it? I would lay very heavily in the “do I have to train people to use it” column, how much work that would be?
Because when you're in sales operations and you're an admin, I think that you're wearing two very similar hats but they're definitely two very different hats. You have sales operations, which are very user base, very sales focused, very sales driven. Sales wants sales ops to be available to help them deal desk, to help them configure opportunities, configure quoting, whatever. And then sales administration, you also have the other departments behind you asking for assistance.
Kristi Campbell: Right.
Emilie Jensen: So, when you have that, you kind of have a conflict of fires, right? And then, you add in user training into that conflict of fires or that confluence of fires, and you're like, "Oh, boy, how much do I have to spend on the phone training sales or reinforcing training with sales? And is that worth my time?"
Kristi Campbell: Right. And ...
Emilie Jensen: So, I think, Yeah, go ahead. Sorry.
Kristi Campbell: No, I was going to say, and then sometimes, I think, the idea that you buy a tool that has training baked in it as part of an implementation package, but there's still an aspect of like, yes, certainly, throughout the implementation, that's either your admins' time, your end users a lot of time to get to that point. You've still got someone that's training that isn't a part of your business. Or maybe I'm just a control freak. But there are certain caveats, right, where we have you do this training and then I turn around and translate it.
Emile: No, I get what you’re saying
Kristi: Or then, I get similar questions because it's more of a generic training versus geared to us. It sounded like a good idea, but it's not necessary. Or when they actually go to do the thing and ours looks different then it feels like the training falls apart, so.
Emilie Jensen: Mmmhmm. Yeah, it's so interesting that you mentioned the looks different part of that, because getting hung up on the user interface, these differences is a huge issue, I think, for human beings in general. And this is why smartphones, when you switch from an iPhone to an Android, you're like,
Kristi: What do I do?!
Emilie: "What is this alien technology? Who are you? And why are you making this noise? And why are you giving me this notification? And I don't understand where to look for anything.
Kristi Campbell: Right.
Emilie Jensen: And it's the same if you're moving between different operating systems or what have you, if your trainer on the solution has just something, just as slightly different, the contact page layout and lightning looks different, columns are in different places, the phone number isn't in the same place or the email is slightly off to a different direction. And someone's been trained to look in the upper left hand corner for a specific information,
Kristi: The Habit.
Emilie: You're going to have to do a retraining, like you just said. It's so interesting how little things are such gotchas.
Kristi Campbell: And especially for your salespeople, like you mentioned there, you don't want them to have to think about those things.
Emilie Jensen: Exactly.
Kristi Campbell: You're trying to make a smooth process for literally sales enablement, right, to enable them to sell the things to keep the lights on and to try and make things easier. But sometimes the change itself feels hard. Whether it's your training or not, I mean, I probably over explain things sometimes, right, because I'm thinking about all those little background things that matter to me that maybe don't matter to my users, so.
Emilie Jensen: Yeah. Yeah. Oooh. That's a good point. Like getting into admin nitty-gritty stuff where they're like, "Well, this object does this. And then you got to have this over here for this reason ..."
Kristi Campbell: I had to do it this way, because ...
Emilie Jensen: And they're like, "I don't really care." (Both laugh)
Kristi Campbell: Come on, this is the fun stuff.
Emilie Jensen: And you're like, "This is how I stay engaged in this training." I have to think about it.
Kristi Campbell: I'm reminding myself why I did it this the hard way because of self reasons. Right?
Emilie Jensen: Right.
Kristi Campbell: But I think the other thing that's interesting to think about is we've talked about knowing your business and your specific requirements. But I do think it's good to take a step back and really remember, well, someone's probably done it before, right? Very few issues, in the end, the broad strokes of what we're trying to do and support with the CRM, especially in Sales Cloud, I think, are pretty consistent. So, I definitely think that there's value in seeing either a product that is available or something, a blog, a video or something of a walkthrough of what someone has done, just to see, really, to get a sense of how hard it might be, or easy it might be to make.
Emilie Jensen: Right. Yeah, I think that's actually ... Sorry, go ahead.
Kristi Campbell: No, I was going to say although then, it's also sometimes easy to start somewhere but then as the complexity grows, right, once you kind of start down a path, you've kind of got to think about the future of if they're going to start asking more things. And then, I've got more things I need to build. Or, if I buy something…
Emilie: Oh my god, yeah …
Kristi: ...Can I grow into it?
Emilie Jensen: How is it going to scale?
Kristi Campbell: Yeah. And then I'm susceptible to their feature release kind of questions. For some reason, I feel like sometimes it's implementing new things, I’m like the roadmap builder finder, where I'm like, "Can you do this?" And they're like, "Nope, but that's a great idea." I'm like, "What?" Okay. So, let's figure out a different way.
Emilie Jensen: Okay.
Kristi Campbell: Yeah, sorry, I had interrupted, I think you had a thought about ...
Emilie Jensen: No, no worries.
Kristi Campbell: You're not as unique as you think maybe kind of sometimes?
Emilie Jensen: Yeah, I think it's interesting, right? And that's where being parts of a community or being good at googling comes into a [crosstalk 00:16:57]. Yeah, I know, that Google. Wow. So, some background, here's so here's a story about something that I built without looking it up. If that's interesting.
Kristi Campbell: Yeah.
Emilie Jensen: I have some hot goss here.
Kristi: (Laughs)
Emile: And guess what, I built it all in Process Builder. So like mea culpa, these are my sins.
Kristi Campbell: Hey, it could have been Workflow rules.
Emilie Jensen: Oh, boy, there were some too, but not so many. I've always hated Workflow rules. And they serve a purpose, but very, very infrequently. So, it was 2016 and I had, I think, very recently received admin access like ...
Kristi Campbell: The power.
Emilie Jensen: The power….
No, it was 2017. It was a year after I received the admin access. And previously, before I had done that, I would just write these really long spec emails, like I had done a bunch of research, I built this idea in my head of what I needed. And then, I would send them to the guy who is now my co-admin. And he would eventually just lose patience and was like, "Just build it yourself. You know what you're doing. Here you go."
So it was 2017 and I discovered Process Builder, and I was gung ho, "I'm going to automate upgrades and renewals like I'm going to automate the renewal opportunity. I'm going to create pipeline in the future for this renewal." And I think I spent like six or seven hours in one of our conference rooms at our old LA office, and I wrote it all out on a whiteboard.
Kristi Campbell: Okay. Love it.
Emilie Jensen: The tiniest little handwriting too. I have a picture, it's hilarious, maybe we'll include it in show notes or something…
But it had everything around like, what kind of downstream processes this will entail? What is needed on a renewal opportunity? How are these going to relate to the opportunity itself? And, you know, really looking back, I wish I'd architected it differently. I wish I had started with a different object as the primary keeper of all opportunities, maybe a contract or whatever. And that's fun to reflect on.
But I didn't Google a dang thing. I didn't look up, “did anybody do this before?” Like, no way. I was just like, "I'm going to just do it. I'm just going to gung ho into it." And man, I really wish I hadn't.
So, the funny thing about Process Builder and things that you'll learn later is you can't debug in Process Builder, so you just have to activate it and pray.
And so, you activate it and then you start praying, and it fails, and you're like, "Oh god, why did it fail?" So you spend a lot of time when you don't do research into “did somebody do this before I did it?” In finding the little bugs, in finding the little gotchas, for me, it was, I really had to accelerate what I knew about automation in Salesforce within the span of a few weeks. And not a lot of people have the luxury of that kind of time to figure out errors. Fortunately, the company was in a position and I was in a position where I could experiment like that.
But I don't think a lot of admins get to do that. I think that by hooking into, "All right, what are the limitations of Process Builder?" Or, "What's going to happen if I create race conditions in Process Builder? How many versions is that going to take for me to figure out?" For me, it was about 17 versions.
Kristi: (Laughs)
Emilie: So, I don't recommend it. Nowadays, I do google.
Kristi Campbell: Is it something that's still in use today? Did it end up working eventually and you kept it?
Emilie Jensen: It was until last year.
Kristi Campbell: Wow. See? It's like ...
Emilie Jensen: I know. It was actually quite good. (Laughs)
Kristi Campbell: It's an interesting balance. It's funny because that's literally something a project I'm working on right now is the idea, so what we're doing right now for renewal opportunities isn't really robust enough.
We don't have a great sense of, like you said, kind of a contract record, something in the middle, that's really telling me what you have right now, that then helps make sure that your upsells and renewals just really stay tight, right? We can get there. But it's just a little harder.
So, do I want to build something where I think I know what we need and I can see what we have, which is working okay, right? It's good enough. But I think it could be better? Or do we look at a tool of somebody that has built something and seen other customers and what they're doing for SaaS products with subscriptions, which Salesforce isn't exactly built for and kind of ...
Emilie Jensen: Yeah, not natively.
Kristi Campbell: ... almost like standing on the shoulders of giants, right, like they've already thought of all the things I haven't thought of the number of decimal points of rounding, and then just one time products versus ...
Emilie Jensen: Gosh, I hate that.
Kristi Campbell: ... subscription product versus tiered products. Just all the different kinds of pieces and, again, not just what we're doing today, but, oh, now we want to introduce a new product or we want to introduce training that's a flat fee, right? So, how does that fit into when everything else is subscription? Thinking through all those things and do we want to bring in something where ... And then partner selection becomes a big part of it too, right? If you've got the ...
Emilie Jensen: You got channel stuff going on.
Kristi Campbell: Yeah. And certain tools, right? Even Salesforce does releases three times a year. And there's plenty of prioritization and all that. So depending on the size of the partner you're working with, if you do make a suggestion or need a feature, then how long might that take to get?
Emilie Jensen: Right.
Kristi Campbell: And can you work around it? Which again goes back to kind of where we started off really having your requirements defined like I must be able to do this. And then if it's just kind of a nice to have, then maybe you can wait a little while.
Emilie Jensen: Yeah. So, it's interesting, you and I have talked about this before personally about renewal opportunities and how do you do it? And I really did actually, after you first asked me that question, I think it was back in July or something. I spent a while really collecting my thoughts about it. What is it that needs to happen? And I wrote a pretty good blog post on it that I think I'll share with you later about, really, you have to have a strong architecture philosophy before you implement things that have object creation based specifications, I think.
Like if the architecture philosophy is there, it makes sense, then you don't really need to develop one. But in the case of renewals and subscription-based renewals and upgrades, I think that Salesforce does not inherently have that. Now, if you go and you sign up for a dev org on salesforce.com today, you'll have access to one of their newer features called Salesforce Billing, which is very interesting and something that I mean, basically, having a dev org caused me to ask my account executive about.
So, that's kind of another buy versus build situation. Do I want to look into Salesforce Billing so that I can have better contract, native contract functionality. Because it basically increases the functionality on the contract object and adds line items to the contract, which is just ...
Kristi Campbell: Okay. Of course.
Emilie Jensen: ... if you ask me. (Laughs) That also is another pro-con conversation, are you using a billing system that syncs back to Salesforce natively? Like, for example, my company uses Zuora and we have CPQ and Zuora 360 sync. So, that enabled us to push CPQ into Zuora and it pulls data through the 360 sync. That creates a subscription object with subscription line items.
But then, there's the conversation of what's your Zuora architecture like? Are these products coming back in a way that makes sense to a user? So, last year, I embarked on a Zuora architecture rebuild ... Re-architecture of the catalog where our products didn't make much sense because they were built with the architecture concept in mind of them representing product families. So, you had a different product family for X, Y, Z, and they think back as a product to objects in Salesforce as X, Y, Z, but you couldn't assign pricing to them. You couldn't assign an SKU to them because within those products in Zuora were different objects that represented the actual product, the actual skill.
Kristi Campbell: Ahhhh. Okay.
Emilie Jensen: So, it doesn't work with standard products and standard price books in Salesforce where you need to have SKU X and that has a price, or it has five prices and five price books.
Kristi Campbell: Yeah.
Emilie Jensen: We had SKU X and it didn't compute to another SKU...
Kristi Campbell: Okay. Well, [crosstalk 00:27:49]. I do think that coming into scenarios like this, right, I've only been at Cirrus Insight for about six months. And I think it's important, especially coming from my last job, there was somebody who came in and kind of questioned things in a very mansplaining feeling like why did you do this? And I think it's ...
Emilie Jensen: Just a little Aggro.
Kristi Campbell: Right? It's like I tried to assume that you did the best you could at the time with the resources and time and money that you had, right? Or the features that you had, right, to your point, just now we're getting contracts with contract line items as out-of-the-box options with Salesforce Billing, right? I haven't looked into it. But as that example, right, there may be something Salesforce has now built that makes it silly that you built all this custom stuff over here. Or that maybe replaces the need for you to buy a tool. Not that the Salesforce tool is always the cheapest or the right fit exactly.
We probably did it that way at the time because it made sense or because that's all the time we had or because that's the way I knew how to do it my first year as an admin, right? Not that it was the best but ...
Emilie Jensen: Process Builder.
Kristi Campbell: Right.
Emilie Jensen: RIP me. (Both Laugh)
Kristi Campbell: And as soon as you thought you were getting, right, there was a time when that was the new great thing.
Emilie Jensen: That was the cool thing.
Kristi Campbell: And now, we're on of the next new great things…