Drew Frayre:

That's a great question, Chara, and one that's very close to my heart because I recently hired my first replacement Ops hire here at Okendo. I lost my direct report to another company and have been replacing that role. I actually just got a new person recently, so I've been thinking a lot about what makes a good Ops hire and what skills I want in this person.

Starting out, I think at a base level, if you're going to be successful in Ops, you have to be very detail-oriented and organized. I'm lucky there because I have very poor short-term memory, so I have great documentation practices and organization that I use in my everyday life to make sure I don't forget things and things stay a priority when they need to be. That's what has set me up for success in Ops more than anything else. I've worked with Ops people who aren't as meticulous, and you need to have a system for keeping an eye on things and building checks and rechecks to ensure your system functions correctly. With six different teams, there's always weird corner cases that pop up, and I hope I've built alerts and flags into my systems to let me know when something isn't functioning as it should.

Second, being a tech native is crucial. My career started in technical SEO because I was good at building computers. My former partner built the NSA supercomputer they used for data monitoring. We bonded over our mutual love of hardware, but living online, building computers, working with software, and knowing how to troubleshoot things is huge. If I find someone with a combination of those two qualities, I'm already off to the races because I know I can teach them our systems. Third, having familiarity and some skill in whatever CRM or systems you're using is important. Everyone uses different tech stacks, so it's hard to find someone with perfect overlap. When hiring, we had 200 applications for the role, and around seven had HubSpot-specific experience. But having experience with any CRM is beneficial.

‍

Chara:

Meticulousness, being tech native, and familiarity with the systems they'll be working with—these are crucial qualities. It sounds like gamers who tried installing, playing, and troubleshooting games in the Windows PC world might also be a good fit. Would you agree?

‍

Drew Frayre:

Yeah, you absolutely caught me. I build computers because I'm a hardcore gamer and do a lot of gaming in my free time.

‍

Chara:

Awesome. Let's say you found that hire. How would you lay out the 90-day plan for a RevOps leader or an individual contributor? What would be the first couple of things to do?

‍

Drew Frayre:

Absolutely. It will be different for every company and role, but at the most basic level, your first 90 days are about discovering and understanding the lay of the land. For my most recent hire, I had a backlog of projects I wanted him to get started on, but I wanted him to understand the organization first. Okendo is uniquely positioned with multiple different teams, which presents a unique challenge. The first task was to get an understanding of the organization and how it works. Meeting with stakeholders in each team, getting a feel for their pain points, and understanding what they're doing is crucial. Spending the first few weeks meeting people and understanding their workflows is essential.

Next, you should start looking at the system and how things are functioning. Begin identifying quick wins. When I joined, I noticed a lot of issues in our HubSpot system that I knew were quick wins for me to tackle. Getting a handle on the tech stack, understanding the workflow, and starting to build relationships within the organization are key. Finally, start working on some of those longer-term projects and initiatives that will have a bigger impact. The first 90 days are about building a foundation of knowledge, relationships, and quick wins to set yourself up for success.

‍

Chara:
Awesome, great. So, let's say you found that role, you know, you found that hire there in the job. How would you lay out the 90-day plan for, let's say, an Ops leader or an individual contributor, right, who's going to be able to create impact in that first 90 days and sustain it?

‍

Drew Frayre:
Yeah, absolutely. And that's interesting coming from my perspective because I have a lot of different stakeholders, and it's very difficult to onboard someone and get them started across six different teams at one time. I'm really struggling with that myself right now as I onboard my new person. I think coming in the door, it's ideal if you can limit your scope and your reach to focus on a single area, optimize that area, and then move forward. For instance, when I came on with Okendo, I focused entirely on the outbound sales motion. I made sure the outbound sales motion was set up with a foundation that I really liked. We were looking at the correct data, they had the right automation to support them, and they had their dashboards and things to look at. Once I had outbound sales in a good spot, I put a kind of stick in the ground and said, "Great, this is complete. Let's go look at our inbound sales motion." Then you can find a typically good way to move on from there with whoever has more overlap with a team. You can move on to that team next, but I really like taking it piece by piece. I know some people say multitasking is a myth and that it's impossible to multitask and be really effective. That's kind of why I like to take things piece by piece when it comes to a company, especially one that has as many different stakeholders and orgs as Okendo does.

‍

Chara:
Got it. So, one of the things that DevOps runs into typically, right, like you mentioned, it's a good idea to start things one by one. Make sure that your outbound is sorted, then your inbound is sorted. Any other process, pick up one process at a time, refine it, make sure it's functioning according to plan, and then move on. This leads me to the next question. It's very easy, especially when you deal with six teams or multiple stakeholders, to get stuck in that one process and keep piling up because of, "Hey, this thing's broken," or "I need a new process here, I need new automation." So, while you're going through this, how do you avoid that trap of just doing the tactical things and requests and make sure that you're pushing yourself as a strategic part of the GTM org and not just tackling day-to-day things and getting piled up?

‍

Drew Frayre:
Yeah, that's a really good question, Char. If you figure that one out, let me know. As far as my strategy goes, I kind of run the Ops platform at Okendo on two different levels. I have a day-to-day ticketing system that I've set up where people can input requests based on existing systems or things that aren't working correctly. I can triage and place those tickets into our backlog, basically running like an IT or a success org but internally. That allows me to prioritize the stakeholder requests. On the other side, we have larger-scale things like OKRs, the quarterly goals we're working towards. I am prioritizing problems or new things that need to be built with my key stakeholders, my execs, and those are typically the higher priority items. Of course, if it's infrastructure breaking on the back end that we have an issue with, we can prioritize that above. It's a mix of these large-scale goals, which are typically builds or optimizing certain arms of the business, and gauging that against what we see in our day-to-day requests from stakeholders. We currently use Slack. We have a Slack channel called Help RevOps where anyone can come in and ask questions. This functions as a good way to school your junior employees. You can have newer employees working within that tool, and when someone says, "Hey, why was this lead assigned to Sarah? It should have been assigned to Jamie," that's a great time for your newer Ops hire to go in and diagnose within Revenue Hero, which is super easy. They can pull up the detail log and all that. They can look at why things were assigned a certain way. Then there are larger-scale questions like, "Hey, can we have the capacity built into our sales pipeline to start to track churn reasons as well?" It makes a good mix of those things, which I really like plugging my junior level RevOps hires into, and then I can focus on the higher-level OKR stuff.

‍

Chara:
Got it. So, it's interesting that you mentioned ticketing. Do you have predefined SLAs? Do you revise them month to month? How do you get your stakeholders to agree to those SLAs? Do you have conversations where you determine what your policy is on these, and do you allow any flexibility with the SLAs?

‍

Drew Frayre:
Yeah, typically our SLA isn't really around a certain amount of time for a response. Our SLA is around giving a delivery time for a question or a request within 24 hours of the request being made. If it's an easy solve, we'll solve it immediately. If not, we use an integration with Asana, so we'll ticket the post in Slack. It will create a ticket in Asana, we'll assign it a priority, and we'll assign it a due date based on where our other priorities lie. That tracks back to the Slack task, so we can always update our stakeholders on that. Typically, it's based around responding within 24 hours and letting them know when it is possible to address the request, and we'll give a due date if it's possible to address.

‍

Chara:
Makes sense. Given that you manage six different teams, do you have favorites where sales get quicker due dates and marketing gets longer due dates, or is it fair to all?

‍

Drew Frayre:
It's really about the person asking the question. I've discovered a new frustration or passion of mine, which is communication. It's interesting the way different stakeholders in an org will try to communicate with you. I always try to say, "Talk to the RevOps Help Channel like you're talking to a robot or like you're writing a program." For example, "This deal came through with billing active. Why did it advance to this stage?" We have people come through and say, "Hey, why didn't this fire?" and link to a record. That's really frustrating because I have to ask three more questions about what "firing" meant in this case and what they expected to happen. I'm definitely biased towards my more effective communicating stakeholders, but I'm also dedicated to cultivating an atmosphere for more effective communication in the org. I'll ask clarifying questions in such a way that it's like, "Oh yeah, I should have thought about that when I was asking the initial question because the way I phrased it makes no sense."

‍

Chara:
Makes sense. I think talking to Ops like you talk to systems should be a more commonly adopted practice in companies. Have you ever tried making a GPT of this within your org, given that it might be the best way to train folks to talk to Ops without ambiguity and just get to the point so they get answers?

‍

Drew Frayre:
I haven't tried that yet, but that's actually a really interesting use case. I am subscribed to the HubSpot-specific GPT right now, and I use that a lot for creating my code snippets and things like that. As experienced and as technical as I am, I still can't code worth a damn, so I lean on GPT a lot for that, and the HubSpot-specific GPT has been very useful.

‍

Chara:
How do you keep up with all the new products to identify which one could enable a massive unlock for your org? Do you have specific places that you go to?

‍

Drew Frayre:
That's a great question, and something that my network deals with as well. Realistically, they're all sending me an email or a LinkedIn message about the product at some point. I ignore all of those, of course, but once you get through the outbound requests, I find that talking to my network is really helpful. On LinkedIn and other platforms, I can't count the times I've had a request come in and I've had no idea how to address it. I'll turn to my RevOps leaders on LinkedIn and ask, "Hey, what are people doing for job change flags in your target Enterprise accounts?" or "What are people doing for point-of-contact identification?" I get amazing answers from people willing to share for free. Leaning on your community of other RevOps users is huge. That can be on LinkedIn, in power user groups for CRM or larger software. I'm in the Discord for HubSpot power users and ask questions there a lot. By following those feeds, you'll see people heralding the next new big thing. That's how we found out about Revenue Hero in the early days. We saw other people in RevOps talking about it and the comparisons to Chili Piper, which was the system we were using at the time. It pays to keep your ear to the ground and continue to network.

‍

Chara:
Awesome. I expected Slack communities, but I never guessed a Discord group for HubSpot. That's news to me. Any other specific communities that you have in mind before we move on to the next question that the audience should be aware of?

‍

Drew Frayre:
I lean on a lot of ex-HubSpotters who I used to work with, and they are great to talk to. People who have gone into consulting, I find, are really good to keep in your network because they are exposed to a lot more than I am with my one job. I can lean on them for the wider lens to help validate an idea or see if it has been done somewhere else. I use RevGenius, which is a really good community for RevOps and sales leaders. You get a lot of valuable ideas in there. So, leveraging communities like those is key.

‍

Chara:
Yeah, makes sense. I think, like you mentioned, consultants just have a collected set of requests. I just can't keep up with how consultants manage all of this. One of the folks we worked with earlier gave a great tip: they have specific hours of the day blocked off for Slack channels from each of their customers, which helps them organize the chaos, right?

‍

Drew Frayre:
What are you guys doing for this? Is this something I could hire you for? If not, what do you recommend? They're always happy to lend a hand and give advice in that regard. So yeah, it helps to talk to the consultants as well. The consultants often have to be on the cutting edge of things because they're dealing with several different clients at once, or their clients have a lot of needs that might not pop up when you're in-house like me.

‍

Chara:
Awesome.

‍

Chara:
So, true, I think the next thing, one of the most popular questions that keeps coming up in a lot of these conversations is, what metrics do you track? For instance, in Okendo, or just in general, what would you recommend RevOps leaders track to display the impact they are having across GTMR? And how do you structure it? Do you have specific dashboards or specific tools?

‍

Drew Frayre:
Yeah, absolutely. And that's really the secret sauce of any RevOps leader, right? It's about what metrics you're tracking. The most important thing for us lately has been churn diagnosis. I am extremely lucky because my team of developers can pass any data you could imagine from our end app over to the system. So, I have tons of amazing product data that I can build my reports, triggers, and automations off of, and that's been particularly useful with churn. Targeting 30, 60, 90-day churn, looking at that across the various market segments of customers, and analyzing why our enterprise accounts are churning has been extremely helpful in identifying how we can retain customers for longer. That's our priority for this quarter and this year. On the other side of churn, the yin to its yang is definitely closed won deals. I like to look at deal close rates across expansion and net new business and, of course, analyzing funnel pickups, funnel conversion rates, deal won reasons, and competitors displaced.

‍

Chara:
Got it.

‍

Chara:
Awesome. These metrics are great. Is there a particular number or trend or just the number of tickets that RevOps is solving that you typically use to see the impact your team has on any of these metrics? Is there a process you have or are thinking about implementing?

‍

Drew Frayre:
I wouldn't say there's a particular metric among those just because of how wide-reaching we are. We're like an octopus with tentacles in every side of Okendo's business. I'd say all these metrics together are what I look at daily. I have a churn dashboard, a deal close rate dashboard, and also attribution monitoring for the marketing side and top-of-funnel stuff. I do a lot of deal attribution as well, looking at referrals from our success team and marketing efforts, all sliced by UTM.

‍

Chara:
Yeah.

‍

Chara:
Mhm.

‍

Chara:
Got it. Since you mentioned you have awesome developers, I'm assuming you get a lot of data from them. Do you have a dictionary or process to translate those numbers into information that your sales and marketing teams can use? Do you use a product for that, or is it more in-house built software and processes?

‍

Drew Frayre:
Yeah, we rely on in-house a lot. Since I worked at HubSpot, I consider myself in the top 10% of HubSpot experts and lean on that knowledge a lot because I don't code and I'm not super technical. We do a lot of unifying our metrics. We work with three different enrichment tools that tell us if our customers have installed competitors. My job is to take those various data sources and tie them together into one unified field indicating if a competitor has been detected. We then build ticketing and alerts for our sales reps to notify them if a big enterprise customer has installed one of our biggest competitors.

‍

Chara:
Got it. I think we have a question around that, Drew. Rich wants to know whether the information you spoke about—the dashboard metrics and tracking—is all done in HubSpot. Could you get into more detail about how that's done?

‍

Drew Frayre:
Yeah, Rich, that's all done in HubSpot. Each of our data enrichment tools pushes a technologies field related to what technologies a customer has installed. I've built workflows that monitor if any of those fields contain a specific competitor. It pushes the date that competitor was installed to a company record, which then allows us to create a churn ticket or an alert for the sales rep.

‍

Chara:
Is that a conversation that won't fit in an hour, or can you quickly explain it?

‍

Drew Frayre:
So far, we're just pushing to company properties with a property like that. We have a field called Technologies Unified, which contains the technologies we care about as a multi-select picklist, and they check off and associate a stamped date for each competitor detected.

‍

Chara:
Awesome. Shelley is asking what data sources you use to determine your ICP and what values you use for that?

‍

Drew Frayre:
Great question, Shelley. For our ICP, we look at existing business and have different ICPs for different customer segments. Since we have great enrichment, we can easily tell the verticals, employee sizes, and product offerings, which is huge for us at Okendo. Okendo is an app for Shopify stores that helps cultivate reviews, set up loyalty programs, product quizzes, referral programs, and surveys. So, Okendo is specific to the e-commerce vertical and the type of products they sell.

‍

Chara:
Is there a specific source you rely on, like ZoomInfo, or is it more form inputs?

‍

Drew Frayre:
We rely entirely on our data enrichment partners for the industry. We've been using StoreLeads, HubSpot, and Charm.io. We used ZoomInfo for a time but stopped due to the cost. StoreLeads is Shopify-specific and has a Shopify rank metric, which helps us figure out if a store is in the right vertical for us.

‍

Chara:
Got it.

‍

Chara:
Awesome. That’s a good segue into another question. Drew, what are some products you are excited about, either ones that are coming up or ones you already use and would recommend?

‍

Drew Frayre:
Hold on a second. Let me pull up my list.

‍

Chara:
Okay.

‍

Drew Frayre:
Okendo has let me purchase and trial many different things to get where I want to go. Our tech stack has evolved a ton in the three years I've been here. HubSpot is huge; we use it for all our go-to-market teams. We use Clearbit, StoreLeads, and Charm.io for improving our company data. RevenueHero is great for meeting routing and assignment logic. Zapier is big for writing cross-integrations with HubSpot and other technology. LinkedIn Sales Navigator is essential for prospecting, and Intercom is used for our success endeavors and bot creation. I also use Whimsical for everything—it's like Lucidchart but cheaper and easier to work with. I have all our assignment processes and builds in Whimsical.

‍

Chara:
Awesome. It’s great to hear another customer's name come up. Seamless happens to be a customer as well. I used Whimsical in product management, and it was a lifesaver for communicating complex workflows.

‍

Chara:
Given the number of tools you use, Drew, how do you ensure adherence to processes? For instance, we have a process where we ask the order form to be updated in a channel as soon as a deal is closed. How do you enforce or ensure that processes are followed, especially in a remote setting?

‍

Drew Frayre:
Absolutely. I've evolved in this over the three years I've spent with Okendo. Initially, our reps had an insane number of tasks and weren't actioning them. What I found important is to give them skin in the game with an SLA. For example, when sales reps close a deal, an onboarding ticket is created, and they must enter information into the ticket before it advances. This makes them accountable, and there's weekly reporting to review.

‍

Chara:
Well...

‍

Drew Frayre:
The ticket is owned by the sales rep until the information is entered. Everyone in onboarding is waiting for the sales rep to complete it. This system ensures accountability and allows us to review and address any delays.

‍

Chara:  

Awesome. So it seems like HubSpot is the answer for a lot of these questions, just really getting creative with HubSpot—setting up some processes and workflows, and most importantly, making all these metrics visible and accessible for the rest of the team. So, you know, if processes need to be added, it’s not necessarily your responsibility. It's just that each team’s owner then gets to know that something needs to move, right?

‍

Drew Frayre:  

Yeah, absolutely. I think enablement is really huge and something that a lot of RevOps leaders get wrong very easily early on in their careers. What I found works is having a standing library of processes broken down by team.

‍

Chara:  

Mhm.

‍

Drew Frayre:  

We use Notion, which I think shares an investor with us. So, we use Notion. Basically, I have a RevOps processes folder. Within that, I have all the sales processes, all the success processes, and all the onboarding processes. That links to both the Whimsical diagram that shows how everything works. Also, I’m a big recorder of videos. I record tons of videos as examples of how to do something because there will be new hires, and people will forget and need to re-watch this stuff. I can see the Loom views that my videos get every day; people are re-watching this stuff pretty often. The most important thing is that they know where to find it. You can build all the awesome documentation and videos in the world, but having that centralized in one page in Notion and then broken down by team is the huge piece so that they know where to go and find it when they need it.

‍

Chara:  

Got it. I think Notion sounds great for that. I have to ask, is there a Notion template by Drew out there that folks can check out? If not, I think you should create one for all the Ops folks to duplicate and use in their own orgs.

‍

Drew Frayre:  

There really should be. I’m working from the standard Notion page, and I’ve built columns for each of the teams I work with. But yeah, it depends on how many different teams and stakeholders you’re working with. The end RevOps processes template might not work well for other companies, or they’d have to delete some of the columns. It’s not rocket science as far as partitioning which team goes to what and making sure you have cool icons for everything.

‍

Chara:  

Uh-huh. Awesome. Whenever we speak about documentation, one of the things that we tried building out many moons ago in a hackathon was how to keep these documents up to date. What we’ve seen, especially in multi-department setups with complicated processes, is that a lot of your documentation expires with time and the addition of new tools, etc. Do you have a review timeline that you put in your calendars? How do you make sure your documentation stays up to date?

‍

Drew Frayre:  

Yeah, that’s a great point. A lot of that comes from working from your documentation when you can. When I have a question about a lead assignment, the first thing I do is look at my documentation to see if it makes sense. Then I go into the actual workflow and infrastructure to see if it matches what the documentation says should happen. If you’re working from your documentation, it has to be up to date, or it’s not going to make sense. I make sure all my documentation is linked. All my HubSpot workflows link to the documentation that talks about them. We have a change log in place that shows when the last time something was updated, so we can go back and see if a page hasn’t been updated in a long time and decide if it needs another look.

‍

Chara:  

Mhm. Do you have an enterprise search product that you use to access these links, or do you think Notion is good enough to navigate all the chaos?

‍

Drew Frayre:  

I think I’m pretty rare in that I have a really disciplined folder hierarchy and naming convention system. But if you didn’t, I could see the need for an enterprise-level search or organization tool. I can typically find everything I need, and it’s nice when you have a team of people because you can easily separate out the responsibilities. When I had an employee working with me, that person was in charge of all assignment flows. It was very easy when a request came into the RevOps channel. If it was a question about how something was assigned, we knew exactly who should handle it—it’s Nick. For onboarding, I built our whole onboarding process, so if there’s a question about that, it’s my responsibility.

‍

Chara:  

Got it. Is it fair to say that your team already owns specific parts of Notion, so it’s not too difficult for them to navigate, as each one knows which page to go to?

‍

Drew Frayre:  

Exactly, and we have the RevOps section and the HubSpot processes section, which everyone goes to, and that’s broken down by team.

‍

Chara:  

Awesome. Slightly controversial maybe, but depending on company stages, is there any scenario where you would recommend Salesforce over HubSpot? Why or why not?

‍

Drew Frayre:  

That’s a good question. I have worked with both systems. Back when I was at HubSpot, we had clients who were on the HubSpot-Salesforce integration quite often. People use HubSpot for top-of-funnel stuff and then pass it to Salesforce once the leads are qualified. I think both systems have their strengths. Salesforce is good for detailed sales process changes, lead routing, and data reporting. HubSpot makes up for it with ease of use, and the UI is excellent. It expands to a lot of different areas very quickly. For holistically running a business, I’m a big fan of HubSpot. If you’re just looking at running your sales segment and reporting on that with a lot of detail, then that’s where I’d fall back on Salesforce.

‍

Chara:  

Got it. Drew, I remember you mentioned specific communities where you go for RevOps conversations. Do you have specific people that you follow either on LinkedIn or in these communities that the rest of the community should be aware of? Folks who put out great content, processes, templates—anything that the rest of the community can benefit from?

‍

Drew Frayre:  

The big one I’d recommend for HubSpot is the Sprocket community. They exist on LinkedIn and also as a Discord group, and a lot of interesting stuff gets flagged there. Another one is the RevOps Co-op on LinkedIn, which is more generalized RevOps stuff. I’m sure there are also tons of Salesforce power user groups if you’re a Salesforce RevOps person. Those are the two I’d start with. You will see cross-promotion among them for other groups and more specific groups. I prefer the larger groups because you get more faces on your posts when you’re asking questions or promoting something.

‍

Chara:  

Got it. Shout out to Sprocket and RevOps Co-op, who are partners of ours. I’ve had some great conversations and insights there. We’re almost out of time, and I know, Drew, given that your Ops calendar is probably full of meetings, I’ll just end with this: what is the most ridiculous Ops request you’ve gotten? Did you end up implementing it or walk away from it?

‍

Drew Frayre:  

Yeah, that’s a great question. This goes back to pretty early in my Ops career. I had a request from my support stakeholder who wanted a semi-pooled ownership assignment for inbound support tickets. They wanted new tickets to go to the same rep as a previous ticket if it came in within a certain number of days. It was so much work to track when the last request came in, how many days from that, reset the owners after that period, etc. Modern Drew would push back on that, but new fledgling RevOps Drew built that system. It worked, but looking back, I cringe and think I would never build such a crazy system now.

‍

Chara:  

Got it. I used to work at Freshworks, where we built Freshdesk, the support help desk, and that was one of the most commonly asked feature requests as well. Thankfully, we managed to push back and not build it out as a feature. Given that fledgling Drew built out that process, how do you frame that conversation today when you get complicated requests? Do you point people towards bandwidth and agreed-upon decisions? Do you have a conversation with a different stakeholder to democratize the solution? How do you handle these difficult conversations as an Ops person?

‍

Drew Frayre:  

That’s a good question. What I’ve learned is not necessarily pushing back, but when a RevOps customer comes with a request, I don’t take requests; I take problems. Tell me the problem you’re having, and I’ll offer you the best solutions for it. We can pick from those, and if you’re not happy, we can tweak them or find a middle ground. RevOps stakeholders should come with problems, and you should guide them to the right solutions, not the other way around.

‍

Chara:  

Got it. So, as a RevOps leader, you spend a lot of time helping teams prompt engineer their questions to make sure they’re presenting problems rather than asking for specific implementations. The more I talk about RevOps, the more it feels like an internal product management role, where instead of building

‍

Drew Frayre:  

I think that's a good way to think of it. I've always thought of myself as product-adjacent.

‍

Chara:  

Mhm.

‍

Drew Frayre:  

But we're not building for the product. We're building for the teams, and it's very rewarding. Every day I come into work, I don't know what questions or challenges I'll face, but I get to be very creative in my solutions. I feel challenged and grow every day, which is rare for a job you've been at for three years, right? You'd think it would get boring and settle down, but it really doesn't. Pushing for products probably helps with that, but you never know.

‍

Chara:  

I think all the hard times and ridiculous requests keep it interesting, right? And Drew, last question, I promise. You said that you've been lucky enough to get a lot of engineering support from your team. Would you say that for RevOps in a technical company, engineering support from day one is crucial? Or is there enough no-code/low-code tooling that you can use to set things up to a point where engineering help isn't necessary to build out a well-functioning RevOps?

‍

Drew Frayre:  

I'd say until the point at which you are concerned with churn, upselling, or expansion motions, it is not 100% necessary. But even early on, there are great learnings you can get from your existing customers and passing that data over, which are helpful for compiling ICPs like Abigail or Shelley was asking. Getting data on existing customers and what they're doing within your tools helps a lot, even for marketing and top-of-funnel stuff. So, I would say you probably should consider it at the very least. But if you're working with churn, expansion sales, or upselling, it’s 100% necessary because you need to know what your customers are doing to impact any of those three buckets.

‍

Chara:  

Uh-huh. Uh-huh.

‍

Chara:  

Awesome. Look, it's been a great conversation. One of the things I was hoping Drew would put on his original title is RevOps Wizard, right? We've learned a lot of your magic tricks on this call. Thank you so much for taking the time and walking us through your experience. It's been a great conversation. Where can folks find you? Where do you hang out other than the Discord for HubSpot?

‍

Drew Frayre:  

Yeah, absolutely. You can find me on LinkedIn. I'm listed as a RevOps Wizard and HubSpot Expert there. Feel free to request me and ask any follow-up questions. I love talking about all things RevOps. I also love discussing technical SEO and HubSpot in-depth technical stuff. I'm always interested to see what people are doing in those silos as well.

‍

Chara:  Awesome. We'll be sure to list all those places. Drew, it’s been really great having you. Thank you so much for the conversation. And to everyone who dialed in, thanks for joining Masters of Revenue. We're wrapping up the Ops edition of this, but next month we have an exciting Demand Gen edition of Masters of Revenue, where we’ll hopefully have Demand Gen Wizards to join in and share their experiences and learnings. Drew, this was really good. Thank you so much.

‍

Drew Frayre:  Of course, Charanyan, anytime.

‍

Chara:   Alright. Have a good one.