Analysis Paralysis by Efficient App

Efficient App Frequently Asked Questions
===

[00:00:00] Andra Vomir: I wanna have a candid conversation about when it makes sense for a company to consider hiring us. We're somewhere in the middle between, an operations team member. And in some cases, an engineer and we can get into the engineering side of it later in this episode, when we talk about integrations, but first starting with just the operations side of things, I think most companies have an ops person on their team and that person is meant to be responsible to build out the company's processes and work with the entire team.

And then there's someone like us. So where do we come in? In all of that.

[00:00:38] Alex Bass: So view us as somewhat of a shortcut for the apps person. The. Person internally in operations, they probably have a pretty good understanding of the internal processes, but that doesn't mean that they have the expertise in what software should be used, how the software should be configured.

And I think it's [00:01:00] common that a company will just put, say the CRM project on the plate of the operations person, but take a, a consulting company like us, a business process consultancy, and we have. Over a decade, working with hundreds of businesses to. Extract the processes from them and then actually map them to the various pieces of software internally.

. So having an ops person is incredibly important because. We need someone that is going to be internally championing the software. So they need to be the one that has some authority internally. So we're think of us as an extension of your team.

We can't necessarily go to your team and get them to use the internal processes that we're speaking to, what the ops person can do is they can require the team to do that. And they can put pressure on that and they can essentially take the requests from upper management C. and use that authority [00:02:00] to make the sales managers, the sales reps and people within the company to use the CRM as required.

Whereas someone externally like us, we can just help walk through the process and get the training up and running and get that over to you. But it's going to be more in the customer. Champion's hands the operations person's hands to actually get that executed on and get that information disseminated to the rest of the team.

[00:02:26] Andra Vomir: So in a company where they're big enough to have an ops person. We're what we're, what you're saying is we're an extension of that role for the company. And then when it's a small business, we can work with the business owner

[00:02:41] Alex Bass: yeah. So the, the business owner in a small business is almost always going to be the operations person equivalent because they know the company inside and out, they're typically getting The employees or managers are typically reporting to them and they probably aren't large enough in which they actually [00:03:00] need a standalone operations person.

So that is likely going to be the person that would be kind of our direct point of contact because it's also the business owner. So say that you have 10 employees, the business owner is likely going to be the one that is ensuring that everyone is using the solution, because then it's also up to the owner to essentially say, Hey, if you're not using the software, then you.

We're gonna get rid of you and there needs to be some level of authority behind that. So that's typically going to be the owner in that scenario.

[00:03:28] Andra Vomir: So then switching gears a little bit, we also build integrations and automations. And one piece of pushback that we get, especially from more tech savvy companies is we have engineers. So, you know, we can do this or we can build this or we can manage this. And at the same time, we also see their engineering team sometimes pushing back.

So can you speak a little bit to

[00:03:50] Alex Bass: that? So for, for some context, I actually come from a bit of an engineering background. I was a web developer for many years and [00:04:00] the skillset of building a website, building backend building processes in that way is a different skillset than that of automation and integration.

Automation is a lot of manipulating data. Formatting it in a way that will work across many different APIs, understanding the API, which is essentially the connective piece of software understanding how that will scale. So say maybe you build something for 10 leads to come through. How do you actually build it in a way so that it scales when you have a, a hundred leads coming through in that same timeframe, if you don't do it right.

And account for many different edge cases for the future. Then it will break. So a typical engineer, if they're not doing this is their main job, then they're likely going to not. For all of the data inconsistency that will come with scale. So a, it is a different skillset. B if you have an engineer, you're probably paying them quite a bit just in the market that we're in anywhere from say a very, very, very junior engineer.

Could be anywhere [00:05:00] from say 80,000 to 120,000. And then you start getting up to mid-range in senior and you might be paying them upwards of 200 to 300,000 a year. So to take them off of actually say, building the product or building these tools that are external to your company, really bringing in value to get them to do this process stuff.

Doesn't actually make sense. So let's say that it takes them five to 10 hours to do something that would maybe take us an hour to do you're. Actually paying them about five to 10 times more than you would be paying us for the same result. And the truth of the matter is it's likely not going to be the same result.

It's going to be a result that doesn't have a lot of the edge cases in thought through that we've developed over the course of a decade to put into place. So view engineers is your highest value pieces within the company. They should be the ones in that is actually bringing higher valuation to your company when you're a small business.

You might not have many engineers, so that becomes less of a problem. But when we are [00:06:00] working with say SAS businesses or highly technical companies, it very quickly comes into, we want our engineers to be doing this. And all we can say is that we have still yet to meet an engineer that has this type of skill set.

It's typically an engineer that focuses more specifically on APIs integrations. And it's a, it's a different skill set to do automation than it is to just build engineering products, product ties solutions at.

[00:06:24] Andra Vomir: So then let's talk about trust because that's another big thing. We're helping companies with their ops, with their processes, and now we're building integrations and presumably their company is now relying on an external company, us for this data to pass through and for their business to run essentially.

So what would you say to the people that are worried to , outsource that externally?

[00:06:48] Alex Bass: So this is one of those difficult areas because trust comes from. Trust comes from many different things. Often like seeing a lot of content and listening to [00:07:00] someone, hearing their voice, seeing that they've been around for a while.

Those are indicators of trust. Hearing us speak about these different experiences that we've had across the hundreds of companies that we've worked with. Hearing that we're still in business after over a decade, these are all. Little micro components that lead to trust. But at the end of the day, you will never trust someone out of the gate.

Trust is built over time. Trust is built over working together over time. What we can say from what we've seen though, is that often the copper champion, unless it is the owner of the business will likely churn from the company or change companies. So think on average now we're no longer in the, the, the times where someone will stay at a company for 10 to 20 years.

Often the most talented people will jump between companies because that's where they can get the highest raise of salary. So view the person that is going to be leading the charge as someone that is likely going to leave the business. So the question is if they're the one leading the charge, and if they're the one running with this, are they going to be documenting the [00:08:00] processes so that if they do slash when they do leave, that information is.

Over to the rest of the team to continue working and being able to train and to know what's going on. That's something that's core what we do, because we are not part of the company. We make it a point to actually build out documentation and training. So that if we were no longer involved, your team still sees what was built, how it was built and how to train the team on, on continuing to use it.

That's part of the solution that we're offering. And that is not part of what an internal team member will do. But I do wanna preface this with. Just because there's training involved and this documentation does not mean that is that you are hiring us to train your internal person to do this just because we will build, say integrations does not mean that we are going to train your internal team members, how to modify the integrations and how to build the automations.

We are doing that in the way that is most efficient for us, for us to get it up and running as quickly as possible for your team to use and leverage. [00:09:00] But that does not mean. Our goal is to train your team on how to build all this stuff. Because now we're talking about literally training a team member on how to build automation.

That that is just not a good use of time. And that's also just not what we're charging for. That's not a service that we're offering. It's taken us, you know, five, 10 years to learn this. That would be more the path of us building say a course or something of the sort. So view your internal team members as people that will likely

churn from the company. If you're the owner of the company, that's probably one of the best scenarios actually for us to be the main direct person that we're interacting with, because they're likely to not churn from the company and they can at least take this information and knowledge along with them.

But every path, every part of the way, you just need to view it as the team member that is going to be directly. Interfacing with us is likely going to leave the company. So how do you actually plan for that? And also have this in a way external [00:10:00] with a lot of thought, because it's external, we put a higher pressure on documentation.

When it's internal, there's less of a pressure on documentation. So we're already planning because most of our customers, it is not uncommon for them to have employees that leave the company. That's just part of the process. That is what we are used to seeing every one to two years. So we're already planning for that.

Often people are within their company are not planning for that, or they think it's not going to happen. It will happen. And when it does, it's better to be prepared for it versus having all that information. Also leave the door with that person leaving.

[00:10:37] Andra Vomir: Yeah. Cuz we see that quite a bit. And then another thing that happens is that when an employee leaves another one comes in and they may wanna implement a different software stack, which is troublesome.

That causes a shaky ground for the rest of the company.

[00:10:52] Alex Bass: Yeah, I think one of the most difficult things that we see is when there is internal churn within a company or someone role switching out or someone moving to a different role. And [00:11:00] someone going into that prior role is there's typically someone that's gonna say, Hey, In my prior job, I use this, I would like to use this and we already have systems and processes in place for the specific software at hand.

And there's often a very good reason as to why we chose the software stack that we did. And that's where we also need to be involved in any ideas and discussions of software changing internally. You need to view us as someone that is part of your team. Every decision that you are making really should be ran through us, even adding a custom field into the CRM, look at us as someone that wants to help with that.

We want to make sure that any changes you make will not lead to issues happening. And there's no way to get someone trained up to speed on knowing that if they change a field or they add a value to a dropdown field that may break the API. So when data pushes over to. It will no longer work and we'll break it.

So we are the ones that will be able to call that out. If we hear you talking about, Hey, we wanna add a couple more fields. We wanna change out some software. All this should be [00:12:00] a discussion. There should be a lot of conversation around this happening and anyone coming in and just leading that they will probably put that software in and then they will leave the company or leave the role.

And then all of a sudden what they've done. It's just added something to the stack that no one knows how to use. And no one knows why that has happened. So often what we would do is we will reference a lot of prior email exchanges. We'll reference some of the documentation that led us to get to the decision of where we did, why we chose what we chose to at least get that person to realize why we did what we did.

To show that there's been a lot of thought that has gone into this. Getting someone into one of these core roles, it's not their job to come up with the best stack and the best software solution. That's our job. You are meant to be the person that helps disseminate this information to the rest of the team and to get the team using it consistently and to get the early changes into the solution, through conversing with us and interfacing with us to figure that.

[00:12:58] Andra Vomir: So a [00:13:00] benefit I suppose, of working with us is that you can expect more consistency across the board and more stability in your software stack and your processes when it comes to your CRM and extended tools. Okay. So final question. In terms of working with us, we always talk about a longer term commitment and an ongoing relationship.

And I think sometimes people also get stuck because they're like, well, cool. We have our software stacked now, why do we need to continue the relationship? And I just wanna highlight that. They're always saying this before the relationship is actually continued because I think everybody sees, sees why we're needed once we're in the flow.

But before we get to that place, Can you, I guess, reassure or speak to anybody that may be wondering, what is the point of working with you ongoing rather than just three months? Boom. You're in, you're out and then our team can handle the

[00:13:52] Alex Bass: rest. So when you hire someone like us we are spending the first one to two months.

[00:14:00] Trying to deeply understand the unique needs of your business. So it wouldn't make sense for us to invest as much time as we do. If we were planning on just building something, walking away and not having any more involvement, we've already invested so much time into understanding your unique processes and needs, and that interfaces in with all the integrations, automations, and softwares that we build.

So someone in your. Admin team, for example can say, Hey, we wanna do this. Now we already have the full cohesive picture from all the different departments, all of the different stakeholders within the business that are saying what they need. And we actually know how the data is flowing from everything.

So we could come to quicker decisions that will not affect everything in a negative way more quickly. And that is critical. And no one on the individual team will really have all of that context. Someone changing one custom field in the CRM for their specific needs may have this ripple effect in all these different departments, even affecting say the admin department, because now invoices are no longer generating because a [00:15:00] required field was just added in to one of.

The software solutions. So you need to view us as someone that has actually invested the time and resources into learning your business. And that's also where we're coming into documenting this information. So it says, so in the documentation, we would say like, Hey, like, please let us know if you're ever planning on changing this field or these are required fields.

So don't change them. And that all needs to be communicated so that it could be documented so that it actually lives with the, the systems and solutions that been, have been built out. So it's core that we are actually an ongoing living, breathing per person persons in your business.

Because there's so many moving pieces and it would actually be much cheaper to have someone like us as a partner in your business externally, versus having someone internal that, as we just mentioned earlier, they can always leave and likely have not documented the process on top of that. So we are actually in many ways, a safer.

Option [00:16:00] to have on an ongoing basis and cheaper than an employee, because we are talking about tens of thousands of dollars a year versus potentially hundreds of thousands of dollars a year, or on that high, you know, five figures per year. We're definitely going to be lower than that, depending on what's involved.

And we're going to be leaving a lot of documentation with you while we're working together as well. We typically do a one year commitment outta the gate because we are going to invest the first 2, 3, 4 plus months into really understanding your internal businesses and spending a lot of time together.

And then there's more of this maintenance. Type of relationship where we are just there to talk through different custom fields, talk through different needs of the business as they come up, talk through different phases that they, that come up or different integrations that are needed throughout time and over time, you'll have the trust in us.

And then you'll also see why it makes sense to have us on more of an ongoing basis, because if we're not there, then. Having someone want something [00:17:00] internally, it becomes confusing. Who do you even talk to about that? You may have ad the admin department that wants an additional field added to their QuickBooks online, for example, for an invoice being generated, who do you actually talk to about that?

That person is likely not going to have the context of all the different areas of the business that will be affected by that.

[00:17:18] Andra Vomir: I know I said that was the last question, but I have a couple more, so I just wanna speak to the operations person a little bit. And also the business owner who may be listening that may have to have the conversation with the ops person that may feel, I mean, threatens a big word, but you know, may feel uneasy about having somebody external doing quote unquote part of their job.

So if we're just speaking directly to the ops person, What do you, do you have any thoughts on that?

[00:17:45] Alex Bass: Yeah, so the, the beautiful thing. Working together is that we are not trying to take the operation person's role, or you can reflect it into say the, the founder or the owner of the company. We're not trying to take the role over.

We're not trying to run [00:18:00] your business for you. So what we're just trying to do is take the learnings that we've learned and disseminate that information over to the person that we're speaking to. So actually think of. The person that we're working with as someone that is also going through somewhat of a crash course with us and that versus them having to think through the software that they should be using, they just get the shortcut answer of the software.

Should be used for the specific need within the business, because we've thought a lot about this. We've implemented likely all of the software that you're thinking, Hey, should we put this in Zendesk? Or should we do Intercom? Should we do help scout? Or should we do anything in the myriad? We've already thought through that answer based on the needs that you have.

And now we could just talk to the ops person and say, Hey, we're going to be using this software for these reasons. You said that these were the problems and the pain points that you were experiencing, and this is why. You should be using this. So the end user, the, the operations person, the main point of contact that we're speaking to, they're actually just learning very quickly [00:19:00] what they should be.

Doing within the company and that's actually a, a highly beneficial thing. So whoever is going to be interfacing with us is actually getting quite a bit of additional value just from a learning experience perspective. They can then take this to future businesses, cuz they will. Leave you eventually, unless it's the owner, they will actually have value in what you're doing with that, which is also kind of a, a, a tough thing, because it makes them almost like more employable in a way.

So this person is actually really important. Think of who you're inter you're, you're selecting as the ops person who they're interfacing with with us. This is a very important role. This is someone that you should trust in your business. Immensely. This is someone that should be somewhat of a stakeholder in the business, maybe even own equity in the business.

So they should not be worried about getting fired or getting replaced by us. They should, you should be viewing. This is, this is the, what I wanna be investing into. This is someone that I want to be learning a lot to really level up our business. So that's often why we have the best. With working with the founder or founding team [00:20:00] people that have equity in the business is often one of the best people that we can be working with as the main I guess, champion for the, the solution that we're putting into place.

[00:20:09] Andra Vomir: And just to add to that, I think the ops person then gets to spend more valuable time with the team and collecting information about what's blocking them from doing their job, and then they can bring that information to us and we can work through it at a faster base .

[00:20:23] Alex Bass: Yeah, it's a, that's a really good point.

That's that is the main area where we're not going to be involved. We're not going to be speaking to every team member on an ongoing basis out of the gate. When we first start working together, there are points where we may pull in different team members to work through this and get to understand their processes uniquely.

But then that's where it's really just the operations person who's interfacing with us. That needs to be the one. We are speaking to most and the job of the operations person is really being in tune with the team members and understanding what their needs are and understanding, Hey, this is a need that is actually becoming [00:21:00] a, a large cost internally.

So if we can get rid of this need, because. Someone on the admin team has to manually create five invoices a day. Now the operations person just needs to know, Hey, there's a way to automate this. So now let's speak to efficient app or, you know, a different company that can actually do this. Now the role of the operations person is actually just finding those pain points internally, having conversations with the team members, understanding when that pain is high, because we're not gonna know that the admin person is having frustrations around generating invoices.

and even more so the admin person might just be complaining about the software that they're using. Not even realizing that it can be automated. The operations person is the one that knows, Hey, this is a pain point. It can actually be automated. Or I don't know if it can be automated. Let's talk to the, the team to see if it could be automated.

And then that's where we come in and we can actually speak to what can be done. So there is a very important interfacing. Component to the operations person and the more they could spend time paying attention to the business, paying attention to the areas of where more [00:22:00] revenue can be had and more money can be saved internally.

That becomes the core role of the ops person. More than anything else. The ops person should not be the one that is spending the time. Setting up software, researching software, figuring out how to implement the software, figuring out technically how to integrate the software, figuring out how to train the team on how to use the software without first knowing how to use it themselves.

So there's, there's so much of an importance for an operations person. And I think it's so common that we see this ops person end up wearing many hats and turn into the quote unquote automation integration software person within the company when that's really not the role that is not where the most value is coming.

From the ops role within a company.

[00:22:39] Andra Vomir: So whether it's the business owner that's listening or the ops person or both, when would it make sense for them to reach out to us and what do they need to bring to us? So we can have a meaningful discussion about how we can help.

[00:22:53] Alex Bass: so the beautiful thing is, all we need to understand is where your pain points are.

So if you don't have [00:23:00] any pain points, it's also likely not the time to work with someone externally. When you're feeling. Like you need to implement software to do more when you're feeling like you're using existing solutions too much to the point where you feel like they should be working for you a little bit more.

If there's a lot of manual processes that are happening internally, if there's frustration or if there's just, Hey, I want to build this company so that it can scale and grow and eventually be sold. Then that is the time when you should be reaching out. And all we really need is to understand the priorities and the pain points.

We don't need to know the solutions that you think are needed. We really just need to have a conversation about that. Really speak to the pain points, speak to the software that you, that you already have in place to see if any of it can already be used. But also we need you to be open minded, to be able to be willing to change the software and processes that are in place because after our conversation, We may realize that a lot of the supplementary software that [00:24:00] is, that is in place may not be the right solution for scale.

So being open to having a conversation about what your largest pain points are, largest areas to save time and largest areas of I guess bringing additional value to the company are really the parts that we needed to speak to. And then we can have typically a phased rollout of phase one should be, how do we bring the most amount of value or focus on the most amount of pain in the business to solve that.

So there's nothing that you really need to prepare short of where the pain points, where can valley be had. And let's have a conversation through that. We don't need to know what software you've considered, what software you have necessarily that are using that you really like.

And you wanna keep using that. That's, it's helpful to hear that, but it's not something that you need to have all mapped out. That's just part of the conversation that will. That will come out. As we start talking about the solution, the custom solution that would need to be built across everything.

[00:24:53] Andra Vomir: Cool.

So pain points and an open mind is the recipe. Okay. I think this wraps it up. Any final [00:25:00] thoughts that you wanna add?

[00:25:01] Alex Bass: Nope, that's all cool. All right. Thanks for listening.