Technical Scoping workshop | HubSpot Admins HUG | October 20, 2022

All right, we are here. HubSpot admin hug with Connor Jeffers. I'm so excited to have you here, Connor. Thanks so much for making this happen. We're going to talk about some lives, we're going to talk about scoping, and we're going to do some live scoping, and it's going to be great. Connor, how are you? Is everything working for you? I see everything.

I think so. Do we have audio?

Perfect.

You have, like, this amazing vertical video, and I feel very compressed next to you. For whatever reason.

That is a. So this webinar platform we're in is called Bevy. It has a lot of interesting clerks. I see just the opposite. I see you in a vertical frame and I see myself like, oh, really?

I wonder if we're the same to it.

Yeah, I'd love to hear attendees do. We both are.

We have the same. We have the same video. I don't know.

Okay. We're both vertical, so I don't know. I've. I've learned that no matter how many people are on screen, you always look like the odd one out, but I.

Think it's actually fine.

It's actually fine. So just. Just a little feature to give you some. Some insecurity as you're about to present.

That's.

That's what you need.

You're talking to a room full of people. Is whatever you can do to maximize your insecurity the moment.

Yeah.

Drastically improves performance.

Yeah. A little bit extra adrenaline and cortisol and all that stuff. So, yeah. Connor, happy to have you. Go ahead and take it away.

Amazing. What's up, everybody? Lovely to have all of you. Thank you, Kyle, for asking me to come do this. So scoping is something near and dear to my heart. So with Apps today, we primarily do technical consulting services for customers. And so talk about today onboarding stuff with our folks. Emily, who's our VP of services, puts together a whole bunch of this. We presented a bunch of this at our in person event earlier this year, and then I added some flair also. And thank you to our team for the design. I am not a designer, and any of the content that I show you that looks nice, someone else has made it look nice. Anything that I create has, like, really, really hacked together and then other people beautify it. Um, so what I'm planning on doing is taking you guys through a little bit of kind of like a scoping framework first. Um, and then what we'll do is we'll do some live scoping with maybe a mystery guest, maybe Not a mystery. I like copy, but of somebody else live in the community who has a real problem. And we're going to do some live scoping and then we can probably do some Q, Q and A maybe at the end as well. So if you guys have stuff you want to talk about, throw it in.

The Q and A.

We'll go through some content and then we'll jump into live scoping. So we're going to see if I can do a screen share here. Looks.

While Connor's wrestling with that, I am here mostly to monitor the chat and the Q and A. By all means, use the Q and A. Like Connor said, put your questions there. We'll get to as many at the end as we can. I'll be watching the chat too. If you need clarification from anything Connor's saying or if you want to hop in with a thought, I will. I will make sure to do an audible because now I assume Connor cannot see the chat or anything else and feels like I can.

I have, I have the reason that this is one window. I have an aggressively large monitor like, and so I can see all of you. It's great.

That's awesome. Okay, great.

That makes my job a little window up. We're good.

Yeah. Yep. I can see the scoping hug event 2022.

Amazing.

So, yeah, take it away.

Sounds good. Cool. We'll go ahead and get started. If you guys have questions, throw them into the Q and A. I'll have one or two like live interactive type questions for you to throw those in the chat also. But as a starting point. So when we think about scoping, we sort of think about scoping as kind of these five different steps. I'm going to go through them kind of in a particular order, but that doesn't necessarily mean that they're labeled 1, 2, 3, 4, 5. But one does not necessarily come before the other. And typically when you're doing sort of good scoping, you want to grab as much of this information as possible. And sometimes you're scoping a small problem and you can talk about something in a conversation or a meeting and it's a one off of call. Other times you're scoping something really big and complicated and robust and it takes you 20, 30, 40, 50 hours to really grasp all of it and put together something entirely. And so scoping is really this concept of how do we go from we kind of have an idea of something we want to do to we really have a very clear concept of exactly what we're doing, how we're going to do it, how long it's going to take and who needs to get involved. And for us, we really describe that as kind of going from business requirements into technical requirements. How do we really go from. We kind of have an idea of what we want to. We know exactly how to get there and we know how to build it. So we're going to talk through each one of these. If you guys have questions on it, throw it in the Q and A. I'll kind of go through these. So. So as a starting point, you can throw this one in the chat. But how many of you have spent a lot of hours digging into a problem that someone has brought to you, whether it's a client or an internal stakeholder, if you're an internal person, just to find out that there is no problem, there is no error, everything's actually fine, and it's either user error or some completely unrelated system generating this issue and it's not relevant at all to what you're doing. Seeing lots of hands, that's great all of the time. It is a terrible use of your time. And the most important thing to do in scoping and I, I think ops people very commonly skip over this step because they're just like excited to solve the puzzle is to stop and be like, is this a real problem that we have? Is this legitimate? Is this user error? One big question is, can you trust what is being said by the person who's asking you for this? I think any ops person in a high growth organization, especially if you've been like directly facing like a sales team or an SDR team, you get lots of requests that are like maybe not fully formed, maybe not exactly what. And they're kicking something over the fence. And so what you really want to do at the front end is validate. Is this a real problem and can you trust what's being given to you? Also, is it reproducible? So is this a one off glitch or an error? Is this something that you can consistently say, oh wow, this is an issue, this is something that's common, this is important to us and you also want to validate. Are there downstream consequences or are there upstream dependencies? So what I mean by that is does this problem or thing that you're building or rely on other stuff that has to happen correctly further up in the stream? One of the things that we see happen a lot is we go and build something and the thing that we've built, but the upstream dependencies don't work very well. And so it doesn't matter because the machine that you've built assumes that you're always going to get, you know, square pegs. And you keep getting non square pegs all of the time. And you're the end user's like, how come this machine doesn't do the thing I need it to? I, I keep giving you different shaped pegs and you're like, well, you told me all the pegs were square. So I built a machine to process square pegs. And so what you want to validate is does everything upstream happen the right way? And similarly downstream, are you handing off data or reports or another part of the operational workflow to something that's happening next and they actually can ingest it, they can use it, they can matter it. And the goal of this is really to expand and figure out who else needs to be involved in this conversation. Are there other departments, are there other users, are there other stakeholders that we need to include? How do we actually figure out and make sure that we have everything we need to make this happen correctly? So as an example here, and we're going to go through a couple of these, is problem validation. So a good example of a good problem that you might get from somebody is we are getting too many leads from our inbound marketing activities. What an amazing problem to have. And we can't process them all. We don't know what to do, we're getting overloaded, right? And so when you really want to do that problem is what's the actual problem? Who's involved? Where are we at? The next thing you really want to do is gather kind of what that business case is. And so what you want to understand is what does that problem actually mean? Right? Like that doesn't necessarily sound like a problem. Sounds like an amazing thing to be happening. Like, why is this an issue? Why are we stressed out? And what you want to understand is why is that the problem itself? And so if you start doing something, if you start solving that problem and saying, oh, you're getting too many leads, let me go delete all your forms, like now you have no leads, problem solved. Isn't that great? What you really want to understand is what is the context of the requirement? Why is this important? Why is this something that we have to do? What is the issue that's actually getting created here? And what you want to really start with is not solving the problem as it's described to you. Because someone might come in and be like, we just have too many of these. This list is way too Long can you make it smaller? And you'll do something to solve that problem. And they will be really upset with you afterwards because they'll find out that, wow, you solved my problem, but now we have no leads. And you're like, well, I thought you had too many, so I solved your problems. You really want to understand what is the business context that's being put here and what are some of the constraints that you might have? So you might find out that, well, we could message all of these leads and we could process them automatically, but, well, we don't want to do that for whatever reason. And so you really want to figure out what are the, what's the actual constraints that might be there? Because you might come in and say, if you want a customer portal, I will build you something on CMS Enterprise and this will be really, really easy. But someone's going to come back and say, well, we don't have CMS Enterprise and we don't have budget for that. I'm really upset, even though what you just told me is exactly what I wanted you to solve for. And so you really want to figure out what are the business requirements and what are the constraints that we have. And those could be timeline. We have people that are like, I need a website up, but I only have seven days. Wow. We handle that problem very differently than you handle. We actually have three months. We're doing a rebrand. We know exactly kind of how this is going to work. And so first you want to figure out what is the problem they actually are trying to solve? What's the end goal and what resource constraints do they have to actually kind of move forward with it. So one example of this business case is like, oh, you have too many leads. Like, why is that a problem? And what you might find out is, well, we only have three SDRs. Uh, they're wasting a lot of time on bad fit leads and they're complaining. Everything they get assigned is garbage. So they don't trust us anymore. They don't trust them and they don't process anything. And this is a big problem. We need somebody to help us solve it. Next you want to really define who is that user? Who are we actually solving this problem for? Uh, and one of the things that you want to start with is do they have high or low technical ability? Because the solution that you might bring to somebody with a really low technical ability is completely different than what you might bring to somebody with a really high technical ability. Similarly, you want to figure out are there built in feedback loops and so what I mean by this is, is the person motivated to use the solution that you bring them or do you need to make it really easy to use and you can figure out how much to invest in that solution depending on whether or not they have a built in feedback loop. So a good example of this is like if you've ever seen expense systems, expense systems are terrible because the people who are using them have to use them in order to get reimbursed. And so what it means is no one's investing in making that an easy to use system because you have a built in feedback loop to make sure people use it. Similar reasons for why you see like deal closing processes, like moving something to closed one, really painful, hard to do. It's because they have to in order to get commission and get paid. And so you have to sort of judge how much feedback loop do they have and how much accountability for the success of that system do they have? So that you can determine how easy do I need to make it use to, I need to invest in making this accessible. Similarly, you want to ask where does the person spend their time? So you want to find out, do they log into the system that this is going to be built in all the time? Do they actually work here? Are we sending them somewhere outside of their normal workflow where they spend the majority of their day? And so recently for us, we were looking at a whole bunch of expense reimbursement solutions. We ended up using something that is built by rippling, which is our HRIS system. And the reason is because our accounting team works in there already. That's where they already process reimbursements. It made a lot of sense to give that to them. And even though it might not have had as many features, or even though it might not have been as technically complex, it was where they were already spending their time. And so really enabling and making sure you're meeting those users where they are ensures that you have a really good scope for how you're going to solve that problem. So one example here for continuing on, the same story that we're doing is our SDRs have really low technical proficiency and they primarily work out of HubSpot tasks. And so if we're thinking about how do we build a solution to this problem, we should really think about who we're solving it for. Maybe it's somebody who really only uses a task queue and HubSpot. They don't have a lot of sophistication on the rest of the platform and they just are expecting Tasks to get fed to them, and that's what they want to do. And so whatever we're going to build should meet them where they already are. So the next thing is acceptance criteria. So this goes back to another question, which I'm sure I'll get hands for. How often have you built something exactly as someone has asked you to build it, and you bring it to them and say, here is this beautiful thing I have made you. It is exactly what you asked for. And they're like, well, this doesn't solve my problem at all. And you're like, well, but it's exactly what you wanted. I wrote it down. I said, this is what you needed and this is what it was. And they're like, well, I don't really care because this doesn't solve my problem at all. And so the first thing you want to make sure of is don't believe the solution that people tell you. The example I give here a lot is if you asked somebody for something and they were you, that they need a window, but they've never seen a window before, they will tell you how they need a door and a door frame, but, like, don't actually attach a door on it. And, like, maybe stretch some cellophane over it because I want to be able to see through it. And you're like, do you mean a window? And they'll. They'll be like, what's a window? And you're like, oh, man, you are going to love windows. Like, let me go get this for you. It'll be awesome. And so don't believe the initial solution that someone is suggesting to you. What you really want to do is dig into what. What do they want? What does their definition of success look like? If this works correctly, if it does what you want it to do, what would the outcome be? And you kind of have to steer this person away from somebody who maybe isn't an expert, maybe isn't technically proficient, says, this is exactly how we should build this, and really say, well, what do you want it to do? And if I brought you that, would that make you happy? Because nothing's worse than spending a lot of time and energy creating something. It's exactly what someone asked for, and they're really frustrated about it. That hurts a lot. So you don't want to do that. So the next thing is really defining those acceptance criteria. The example here is SDRs should really easily be able to see which leads they should pursue first. They should know where to spend their time. We should bring those leads to the Top of the list like that, to me, is what I think the ideal solution looks like, even though I might tell you I need something completely different. So one of the last pieces that you want to do here is set exclusions. Really make sure. Does this apply in all scenarios? If I bring you a solution to this problem, is it actually going to solve for all of these use cases, or are there known exceptions to this rule? Are the things that we should exclude every single time or different scenarios that you know of right now that we shouldn't account for? Because nothing's worse than when we implement that solution. And all of a sudden it has all sorts of side effects and false downstream consequences that we didn't think about. And so what we want to do is say, well, what shouldn't this apply to? Is there anything that comes to mind that we should ignore right away? And so in this example, we have the partner team gets leads through too many through our form, and they select partnerships, and we can ignore those. We don't need those. They should go somewhere else. Like, if you take all of those and you give them to our SDRs, they're going to be like, wow, these are garbage leads. I don't want to tackle these. And so we shouldn't include any of those in this overall process. And so when we bring all of that together, what we really grasp from somebody is we have a customer, we have somebody who has an influx of leads they can't process. They're overwhelmed. As we dig in, we're finding out the reason they're overwhelmed is they just don't have enough manpower to call all of them. And we're starting to lose their confidence in the leads that we're creating. We're also learning that the people that are solving this are not terribly technically proficient, and so giving them a really robust, complex solution probably isn't helpful. And we also want to be able to make sure that it works entirely in HubSpot, because that's where they spend their time. And the way that they would be happy and accept what we've created is if we build something that makes it so that they can easily figure out where to spend their time and where to focus. And. And we should not include anything from the partnership team. Now we have a really good idea of what's the problem, what's the spec, how do we evaluate it? Ideally, we're asking, how do you know what partnership leads are? How do we manage those and ask a lot of questions so we can get a lot of fine tooth detail? I don't I think that this was meant to be excluded, but no, it just has really fun animations. So when we really think about kind of what those stages are, is that first thing really validating the problem? Gathering all the documentation, what are those really firm business requirements, how does that, that work? Doing all of your discovery questions, really digging into those business requirements, manifesting technical requirements, mapping out that solution and really documenting, here's how I think this is going to work, here's what the outcome is going to be. Go back and show that to the person and say, hey, here's how we're thinking about doing this. Does that look right? Does it feel right? Is this kind of what you want? Really estimating how long it's going to take you to do it, both from a raw time, which ultimately is cost. So whether you're outsourcing this, maybe you're getting quotes. If you're doing it internally, you're. You're assigning Sprint points, whatever it might be, and how long it's going to take you to actually deliver it and get approval from that end product owner. So good scoping goes from, I'm a person, I have no idea, please fix this, to here's how long it's going to take, here's how we're going to do it, you signed off on it, you're good to go. And so then kind of this last step as we get in here is how do we actually go and give this to other people? So we use ClickUp internally. But an example of this is like when you're giving tasks to other people, if you've done good scoping and it should be really easy for people to do the work that you're assigning to them. And so if you give somebody a task, it should be really descriptive and it tells them exactly what they need. What is the problem, what are the actions they should take, what is acceptance criteria, when should this task be done? A clear title of what it actually is, and subtasks for everything that feeds into it. And so when you give this to somebody, they say, oh, cool. I didn't personally do the scoping, but I have a very clear idea of what we're doing, why we're doing it and how we define and solve that problem. And that's awesome. What's bad is if you do the same thing and you just assign someone a task that says, go make contact statuses and you don't tell them any of the things that are involved in this and you haven't done the scoping necessary in order to make them effective and successful. And so what you want to be able to do is make sure that when you're creating tasks for other people, when you're doing that scoping process, the thing that you're giving to others downstream gives them everything that they need to perform and execute against that work effectively for you and, and actually be able to deliver the solution which at the end of the day is everybody's goal. So scoping is key. Whether you're cert, whether you're a service provider and you work in a HubSpot partner and you're trying customer scoping is the most important part of what you're going to do or if you're in house, good scoping is how you protect yourself from downstream problems. How do you manage your service provider well? How do you manage your teams well is do really good scoping so that you make sure you have everything under, under control before you jump into execution. Otherwise you do tons of work, spend a ton of time, don't get to where you want to go and everybody's unhappy. And so where I'll leave you guys always is always be scoping, never stop. It is not a one time process that you're going to do. Businesses adapt and change. Often this happens after the original ask has been made of you and all are applicable. Everything's moved around and so you always want to be revalidating all of those different pieces to make sure you, you have a full understanding of what you're doing and why you're doing it so that you can actually come in and build a solution that is applicable to the problem that somebody has. So that is my pre content and then I believe we're going to do some.

Yeah. So thanks for that and thank you. So I don't know how many of you noticed this would be a good thing at the end, near the end of this event. I'll drop a link to a survey at the end for feedback. A sort of experimental thing Connor and I did is in the on the event page in the description we linked to a Google form where if you wanted to volunteer to do some have Connor help you scope a project live, you could do that. And we got some submissions. I appreciate all of you who submitted. I'd love to hear if this is a good way to do these sorts of things or not so good way. But I am super excited, super excited to announce that the person who has been chosen that is going to get to do some scoping live is Callie. I just gave you presenter Mode, I think. No, maybe I did not. Yes, I did. Okay. I don't know how this thing works, Callie. I know from just kind of admin stuff in general. We've crossed paths a few times. Super excited to have you here. Hello. Hello. Oh, yeah, hold on.

There we go.

All right, we can hear you. We need like some game show music or something anyway. Yes, I brought Kelly on stage. Connor, I'll let you take it from here.

Does Kelly get to do an intro or is she just like.

It's good.

Lovely to see you again by the way, Callie.

Great to see you both. Love chatting with you guys. Hi guys. My name is Callie Mulvihill. I'm the director of Revenue Operations for Tabouti lms. We're a learning management system technology company based out of Boise, Idaho. Been here a year and a half. Ish. And have chatted a lot with Connor and Kyle. So super stoked to be on with them today, chatting through some of the problems we're seeing.

We're so happy to have you, Callie. Why don't we. Why don't we start? You can kick us off with like, what are you working on? What's going on? Give us some context and we'll kind of ask questions from there.

Yeah, absolutely. So the basis of the scoping draft that I submitted our. Once we're ready to close a deal, our sales process is pretty broken. We onboarded a new ERP last year and we hired a firm to build the integration from HubSpot into NetSuite. ERP NetSuite. So we are using Soligo. So Soligo is hosting the sync to pull all of our data from HubSpot into NetSuite. And it was built kind of exactly like you were saying, for one use case and one use case only. So if we ever have a standard deal that's closing with a discount or non standard terms, our finance team is having to manually recreate that subscription. At the same time, we are also in the early stages of building a self purchase portal because we're a SaaS company and right now our customers can't self purchase our product on our website. They can't self upsell themselves within our tool. So our engineering team is wanting to build a self purchase tool that will create the deal in HubSpot so that we can properly track the revenue there. But we also need to make sure that that is syncing correctly outside of just the sync issues that we've had between HubSpot and NetSuite. NetSuite is not serving all of the functionality that we're needing to. And we use Stripe already for our payment processing. So we use NetSuite to manage subscriptions, but Stripe to manage the actual payment processing. So we are strongly considering moving all subscription management into Stripe, which, hello, Zabra, would be great because then our team could be managing those subscriptions already in HubSpot, which is where they live, to validate the quote. So that's kind of the. The big picture of what we're looking at.

Of. Of the three systems that we just talked about. So NetSuite, Stripe and HubSpot, which one has the most complete view of like this is the accurate that we have of who these customers are.

It becomes NetSuite based off of manual input by the finance team. I would.

Netsuite has like the right information and is the plan that you're going down right now to cut NetSuite entirely or just remove NetSuite from like the subscription management piece and still use it as an accounting solution?

We are considering both. If we can set up Stripe in a way that we're getting all of the financial reporting that we need, then we would strongly consider cutting stripe or cutting NetSuite completely.

What would you use for accounting in that situation and like taxing?

Not sure.

Okay, cool. Is there someone on your side that is managing that piece of it? Is that like CFO or is it finance team or.

Yeah, so our CFO is still in the weeds of that a little bit, but we have an accounting manager who does that mainly. Her team also lives in HubSpot because they're having to do so much validation against Quantum quotes because they're like a.

Deal desk type of. They're like processing those, invalidating them and going back and forth. Yep. Okay, cool. And in terms of the. And Stripe. Stripe is being used for some subscriptions or Stripe is being used for all subscriptions and NetSuite is just provisioning those subscriptions.

Stripe is being used for no subscriptions currently and only being used as our payment processor.

So everything's Getting managed on NetSuite and Stripe is just actually processing the card and then kicking it back.

Exactly.

Yeah. Okay.

But because Stripe has a shopping portal that we could use on our platform, our engineering team is strongly in favor of using Stripe as our subscription manager so that we could use their payment portal on our site for our customers to self upsell.

Do you have any customer portal type experience today.

In a sandbox? Nothing in production.

Okay, what about in app in. I'm. I'm unfamiliar with exactly how Tivuti actually works. Which is like, are those people users in Tavuti also?

Yes.

Okay. Is the person that. Is the user in Tabouti the same as the person that actually needs to manage the subscription? Like they're the admin.

Yes, it would be. That's something. We are using an association label in HubSpot for Tahoodi to read via our API. Who has access or no access to the person.

That's super cool. Awesome. Is that getting fed to Tivuti by HubSpot or is Taviti pushing that into HubSpot based on the Tivuti database?

It's sourced in HubSpot and it's pushing from HubSpot to Taboo.

Oh, that's super interesting. So you guys at like the HubSpot. We'll get back to scoping, I promise. This is just really interesting. The. The. So D is controlling user access or. Sorry, HubSpot's controlling user access and to Booty. So internal. Your internal employees are saying who should and shouldn't access to Voody from HubSpot itself.

Yes.

Super cool. Okay, awesome. So Hubs, that's actually the master in a lot of these situations. And we're sending stuff to NetSuite so that NetSuite can do the accounting and provisioning and all that kind of stuff from there. Okay.

The.

And the end goal here is it sounded like there's two kind of user journeys that you want to enable. So one is that you want to be able to have the associations in HubSpot actually. Well, no, that's already happening to Tifuti. Okay. So you want to be able to have reps in HubSpot. So that's that sales. It's CS, it's whoever's kind of managing and interacting with that customer, you want them to be able to actually go and administer and manage subscriptions from inside of HubSpot. And then you also want to be able to have the customers be able to self update and change their subscriptions on HubSpot somewhere.

Yes, yes.

Okay.

And somewhere along the lines, ensure that whether we're managing those subscriptions in Stripe or NetSuite, the deal data is actually correct and our finance team is not manually creating those subscriptions every time.

Cool. That makes a ton of sense. Is the.

My.

My question here is around the user portal type experience piece, which is. It sounds a little. And maybe, maybe your engineering team is just embedding it straight from Stripe and so it gets validated and it's fine. But that you want to be able to like, is the person going to be logged into Tah Voodi when they're actually updating and managing their subscription or are they. Is this a separate like user login portal experience?

I believe it's an embed. So they should be logged into their to Voodi instance and then see their. Their billing manager within Tabouti.

Yep. Cool. That makes a ton of sense. Okay, so I think, I think based on what you're trying to do, I do think that I know you dropped Zebra at the beginning. Zebra is a product that A8 labs which were is it is a separate entity from A8 but we are we're affiliated with in some degree has a product for a stripe and HubSpot integration. I do think that Zebra would probably work for you guys. The thing that I zabra is going to write and read data from HubSpot back into Stripe and so if you could provision everything from HubSpot. So this sort of solves your. How do we get something into Stripe if it's custom or it's complex and it's not necessarily built to work with NetSuite and you should be able to do all of that from HubSpot from your sales and CS user journey, which should work really, really well. The then similarly, if you're embedding that Stripe self management piece into the product, all of that will then happen in Stripe. Zebra will push all of that data back into HubSpot. So you'll have that whole picture inside of HubSpot itself that that should eliminate. If this is Soligo, the only thing Soligo is managing is NetSuite to HubSpot or are there other parts of the business Soligo is attached to?

Soligo is managing HubSpot to NetSuite and NetSuite to Stripe.

Okay, interesting. So this is where I think that stuff is going to get a little bumpy and we may need to talk to the the CFO and the accounting manager is NetSuite does a lot more than just the subscription management piece. Right. So NetSuite is going to do the accounting, the ERP, the cost basis stuff, all the different things on that front. I believe and I could be wrong here that Stripe has a nets like Stripe will push data to NetSuite likely that maybe NetSuite doesn't write to Stripe, but I believe at least Stripe at a minimum will put all of the the transactions into your bank account and NetSuite could then organize them from there. My knowledge the financial upside is decent enough to have a conversation with these people, but the accounting manager, their CFO would probably have to make a decision there. But what I don't know is what else they need from NetSuite beyond the subscription management pieces. But you should be able to push all of subscription management into Stripe. And then the question is, can you Access inside a NetSuite some other type of data to be able to do the accounting and financial and budgeting and those sorts of workflows that they need, or do they need to be able to go into. Can they get that from like the bank transactions? Right. So for us, for example, for the software business, all of that runs through Stripe. That all goes into Chase. And then Chase is connected to the erp. And so the ERP just says, oh cool, this is what these are for because they get tagged from like Stripe deposit metadata stuff. You can also export all that from Stripe. But again, I think we'd need to talk to the CFO and the accounting manager for that particular piece, because I don't. They're going to need some kind of ERP solution, I think, but maybe not. Maybe you guys can get away with QuickBooks and it needs to connect to Stripe and They only got NetSuite for the subscription management piece and Stripe would solve for it. We'd probably want to talk to them. That kind of goes to like, what are the downstream impacts of ripping that out? My guess is they're a little bit more significant than we might anticipate. And then you can embed, always, always you can embed all of those details inside a Stripe for sure. Manage and write everything back and forth to HubSpot and that should work. The other benefit of that is you should be able to do something similarly like your association workflow you have today and like link the subscription in Stripe to the, to the contact inside of HubSpot kind of the same type of way too. So you could actually delineate between who's like the admin and interaction versus who's actually allowed to interact with it inside of Stripe. You could start to push some of this into like a CMS sub enterprise thing. But I think that that's probably if you're. If you already have to voody the application, you don't want to have this like dual login concept. So embedding that direct from Stripe into TV makes a lot of sense and I think that that all should work. And the thing that I would want to dig into quite a bit more is what else is being done in NetSuite. And if they drop NetSuite, does everything else start to fall apart? The other thing to think about is managing credit cards and migrating subscriptions. And those other pieces are. Is tough and complicated and scary. So that's probably one thing if you're thinking about, like, exclusions and big risks, is to dig into because it's really like, they're like, oh, well, we don't actually know because it's all PCI and nobody's really motivated to help you. It is possible. Like, we've seen lots of different payment processors move over to Stripe or from Stripe to other solutions, but it's not exactly a. We'll export it and we'll import it, we'll turn it all on and we'll call it a day, unfortunately. So what I would suggest is the next step from here would be to chat with the accounting Manager and the CFO and understand what else is going on in NetSuite that we might not know about, as well as validate and test some of those use cases on like a zebra trial or something else and find out if. If you can do everything you need to do with zebra, if there's stuff that is missing that you're similarly experiencing on NetSuite so that nothing's worse than saying, hey, we're going to make this whole switch doing something. And then you're like, ahaha. And doesn't work well either. We're sorry. And those would be my suggestions. And I'm happy to do that with you, as always.

So if I could hop in here and just be. Please, you know, the. The educational stickler that I am, I would really love it, Connor, if you could share your screen again and bring up your slide that has like the five.

Yeah, let's do it. Kyle's gonna hold me accountable.

How rude. Yeah. And I mean, if I was a really stickly stickler, I would force Callie to talk through the five points and see if she's gotten them. But I am. I mean, I know we're in front of an audience.

I don't mind at all. Let's. Let's rock and roll. I will pull it up right now. Be forewarned, future guests.

People say I'm nice. People are mistaken. So I don't actually know. Connor, do you want to talk through them?

Or I can give it to Kelly. I don't know. I can restate what I think each one of these is. Is that. That's probably.

So.

I'd say I think the problem is validated. The one thing that I don't think that we have is Kelly had suggested that maybe we want to flush netsuite entirely And I think that we want to validate quite a bit more that that is actually the case. I think that that also applies to exclusions here. I think that there's quite a few exclusions that we need to dig deeper into to understand that accounting profile that kind of ties a little bit into the define the user as well. I think the business case is pretty clear. We both want to have this end user upgrade, downgrade type of experience. The stripe embed should be able to support that. We're going to need the engineering team involved for that also. So the change management here is pretty robust. But we also want to be able to have that user experience in app which Zebra should be able to power. You should be able to do all of that straight from HubSpot. And the acceptance criteria here would be accounting doesn't completely fall apart I think is a maybe given one and that user end users can upgrade and downgrade themselves and that internal users are able to manage subscriptions all inside of HubSpot and maybe that we can save some money. So Soligo, I would sort of add that in there as like that's probably kind of an end goal here as well. I would say I didn't dig into that enough as I'm reflecting on this for what's the actual motivation? Why, why is this a big problem? Is it just time savings or is there a cost reason? So I'd say if I did anything weak it was probably going deeper into the acceptance criteria. So I give myself like a four and a half out of five as my self diagnosis.

Callie, how does, does that match with what you got out of the conversation? Is there anything he missed or anything?

Yeah, absolutely, I think and kind of just like you said, Soligo is absolutely our pain point. It's not that NetSuite is, you know, terrible because NetSuite is used by many enterprise, you know, customers. It's how our integration was initially built in Soligo. And so losing that tool and losing how much we get blinded from what breaks until we go is a huge benefit. So it's time. It's exactly what you're saying.

Those are assumptions though. So I should have, I should have dug into it a bit more. But I, I, I got that was the vibe of like we're not super into Soligo, bad implementation, some of those other pieces. So I give myself a half a.

Half a point of fact and not to hate on Soligo. It was, it's absolutely what we have currently running in Soligo. I'm sure Soligo is a Great tool. So if you're it, don't be afraid of our circumstances.

Well, awesome. Thank you so much, Callie, for coming on. Any last things you wanted to cover before?

No, I think it was great. I liked the live implementation of what Connor was chatting through, so I think it was cool and always fun to talk to you guys.

Yeah, thanks so much for being here. You're welcome to hang out on stage with us if you want, or you're welcome to go off camera. Now, Connor, I wanted to ask sort of a couple of. There's some chat about diagramming and I noticed while you're asking Callie questions, you were typing. Are you just taking quick notes on a notepad when you're scoping things out, at what point does it become necessary to jump in, like lucidchart? How do you think about documenting this stuff?

Yeah, for sure. That's a great question. So we do two things. One is we record all of these. So we use a VOMA internally, which is a super cool tool I'd recommend to folks it syncs with HubSpot. It's awesome. But one is record it because you might need to go back later and review it. Even if you just do that in Zoom, there's tools that will help you do that and make it easier. But I think that's a big. A big piece. I take a lot of notes. I did like debate in high school and so I'm really, really good. I'm really good at flowing notes and I like, send them a lot to my leadership team and they're like, you wrote all of this down? And I'm like, I can't help myself. It's just like flows out of my hands. So I do a lot of note note taking. Our solutions architecture team very frequently does live diagramming. I actually think that that's like, I'd recommend that to people. I think it's a really good way to validate kind of your thoughts. The reason that I would say I didn't jump into that on this one is there. The data flow wasn't that complex. Right. Like, we were basically talking about going from HubSpot to Netsuite to going from like HubSpot to Stripe, and there wasn't that many. I think if we started getting into like objects and records and what needs to think where, like, we would absolutely want a diagram to do that. We got into that is if they were like, we want to keep NetSuite. We want data to go this way and we want data to go that way. And then we'd be like, okay, let, let's get a diagram in place so that we're all talking about the same thing. And I think that doing live diagramming is a really, really good way to get on the same page as whoever you're talking about. And I'd recommend that to most anybody for sure.

Cool. And then the question that was bound to come up eventually with you and I being here together is Zebra versus HubSpot payments.

Yeah, so I wouldn't say it's versus at all. We actually, we did a webinar with the HubSpot payments PM and Stripe and talked about Zebra. I can, I can drop like the recording link in here if anyone wants to check it out. Yeah, I wouldn't say that. All verses. So the very short, short answer for me is I love HubSpot payments. We've built a lot of projects on HubSpot payments. We use HubSpot payments for some stuff internally. So we have like upgrade packages that people can self select and purchase. And the value of HubSpot payments for us was someone said, hey, we have these customers that are on small service packages with us that want to buy like 10 more hours of support. And having a salesperson talk to that person and then sending them a quote, like a huge waste of time and money. It's really, well, what if we just gave them a page to just set this up and they could just transact and it would be really, really easy. And then Hubs Payments lets any small and small business isn't. I was actually funny, I was trying to like a public markets analyst like yesterday about this and trying to explain it to him. It's easier to these people though, for sure. Which is, it's not about small business. It's about simple payments workflows, right? So you could be this huge H Vac company with like thousands of employees, but your business is ultimately like, book a meeting with me, right? And I will come to your house and I will fix your AC unit and you will pay me for that. And that's like, that's it. That's the entire level of complexity. And HubSpot Payments is awesome for those use cases. Stripe is a huge complex payments infrastructure system that's made for like so HubSpot, right? All of HubSpot subscriptions run on Stripe and you have entitlements. So it's like what products is someone paying for? What features should they be able to access? Being able to do like Uber or Instacart or like any app to doordash, whatever app you might use for any of these things. Ultimately you end up booking a Uber drive. And Uber doesn't collect that money and then pay the driver like you pay. Stripe then has logic that determines how much should the driver get paid, how much should Uber get paid, and it manages all of that. And so Stripe is really about turning financial infrastructure into code and letting you build software stuff on top of it. And so Zebra is ultimately we go to people that are using Stripe because they need a high level of technical sophistication and we're just like, we'll take all your Stripe stuff and put it in HubSpot and that would be awesome. And HubSpot payments is actually a product built on top of Stripe to make it easy for SMBs to do payments. And it's amazing at that. And I recommend it to anybody. And Stripe is like a big complicated solution that you can build crazy stuff on top of. And if you don't need that, like don't, don't build stuff on top of it. Like it's expensive. And like Zebras, I think it's like anywhere from 3, 200 to 300, $600 a month at the high end. So it makes a lot of sense if you have that level of sophistication. But you'd look at this and be like, well, why wouldn't I just use HubSpot payments? And our answer, like, if you can use HubSpot payments, you definitely should. Like, you should not do anything more complicated.

Cool, that makes a lot of sense. It just my perspective as a person inside HubSpot is that a lot of our customers aren't doing any sort of online transactional payment stuff at all. And if that's you, if you're in the U.S. by all means start using HubSpot payments and play around with it. See if people want to pay for a consultation or pay for an on site visit or whatever it is you have you could charge for and that could just be a new revenue stream for you. But it sounds like if you already have a super complex thing running on Stripe, you're probably not going to be able to just leave Stripe behind and use HubSpot payments and be fine.

Totally. And that's sort of where we think about it. And I don't know that HubSpot payments, and I have no idea what the product direction is. Long tail, right. But I don't know the HubSpot payments wants to go and be the level of complexity of Stripe. There's a reason it runs on top of Stripe and I think that where HubSpot payment solves an amazing problem is what you just said, which is like, there's tons of people who. The best example that I have is like, my mom was telling me a story. This is hubs payments. And then she wasn't as excited about it anymore, but she was telling me a story about she was going to this massage place and she had like a. Like a membership, like a subscription membership to this massage place. And they had stopped charging her like three, four months ago. And she didn't know, and they didn't know, and she just kept going and getting massages and it was great. And then one day they're like, wait a minute, you owe us like $400. And she was like, I owe you $400. And they're like, yeah, you do. And she's like, well, that seems crazy. Like, why would I owe you $400? And she's like, well, I don't have this $400. And it was this whole problem. And like I was. This wouldn't even have to be a problem ever, because the person checking you in would be like, oh, we have this membership subscription for you. It's current, it's accurate, it's all great. And for that business, it's just we charge you 100 bucks a month and that's it. And it's. And I think HubSpot payments is incredible for those types of use cases.

Awesome. Thanks for pursuing that tangent with me. Because it was a question in the chat coping shadav asked in the Q and A, should we have a playbook during live scoping? If yes, do you recommend a template that can cover all general but essential questions?

I think the deck that I shared and I'll send that to Kyle and we'll get it redistributed to you guys as well. You're welcome to have it. I think those are kind of the general as I think about them, big picture stuff to look at. We have this conversation a lot. If anyone has a playbook and I'm wrong, like, please share it because I would love to have it. In all honesty, I think one of the things that's really hard about scoping is scoping is required because problem and unique and not something that someone has solved before. And as a result, you have to go through the scoping process. So to have this baked list of questions, like if I had a big list of questions and I was asking Callie, you know, well, what do you use for payment processing? And what do you. And we weren't talking about anything related to that, she'd be like, why are. Like why are you asking me these questions? It has nothing to do with what we're talking about, but I think what's really important is to kind of get the general picture and when you look at that, be like, can I restate the problem statement and the business case and the exclusions and I could get a firm handle on what we're talking about versus make sure you ask these specific things. I think the thing that makes scoping fun and interesting is that it isn't as templated as it otherwise could be because it doesn't have a discrete outcome.

Awesome. So thank you for everything. If anyone else has any last minute questions, drop them in the chat now. Or I was gonna say or forever hold your peace, but actually that's not accurate. Connor, if people want to get in touch with you, where can they find you?

What's the I am on LinkedIn. I am accessible by email. I am. I am very reachable and I'd love to talk about all of your problems. So LinkedIn's probably the easiest place I'm pretty active on. I check it a couple times a day so LinkedIn's great. Should hang out with me there.

I also love LinkedIn, so I see. One last question from Brandon. We'll finish on that one. I am dropping a survey monkey link into the chat. Please everyone, give us some feedback. It's just two questions. One's a standard NPS question and the other is just a text field where you can tell me what you think about this and the admin hug in general.