Episode 319 | Questions about the Technical Side of SaaS

Startups For the Rest of Us

Episode 319 | Questions about the Technical Side of SaaS

Play Episode Pause Episode

Mute/Unmute Episode Rewind 10 Seconds 1x Fast Forward 30 seconds

00:00 /

Apple Podcasts Google Podcasts Spotify Stitcher

RSS Feed

Share

Link

Embed

• Facebook
• LinkedIn
• Twitter
• Email

Show Notes

In this episode of Startups For The Rest Of Us, Rob and Mike answer listener questions about technical sides of SaaS. Some of the topics include pros and cons of including marketing website in main codebase, SaaS quality, and re-engaging a cold email list.

Items mentioned in this episode:

• Drip
• Codetree
• Bluetick
• Drip Knowledge Base
• LeadFuze

Transcript

Rob [00:00]: In this episode of ‘Startups for the Rest of Us,’ Mike and I answer several listener questions about the technical side of SaaS, and we also talk about how to re-engage a cold email list. This is ‘Startups for the Rest of Us,’ episode 319.

Welcome to ‘Startups for the Rest of Us,’ the podcast that helps developers, designers and entrepreneurs become awesome at launching software products. Whether you’ve built your first product or you’re just thinking about it. I’m Rob.

Mike [00:31]: And I’m Mike.

Rob [00:32]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, sir?

Mike [00:37]: Well, I think I mentioned a little bit in the last episode about some of the scaling issues I’ve been running into, and one of them I got kind of kicked into the groin this morning about. I logged in and checked in my server bill is on track to be about $500 more than I expected it to be this month. So I kind of have to drop everything –

Rob [00:53]: That’s not good.

Mike [00:55]: No. It could be one of two things. It could be just like I have the wrong size for the server. But my sneaking suspicion is that it’s actually a licensing issue. So I switched over from one program to another inside [Avisure?] and I feel like they’re charging me a heck of a lot more than I probably should be. Unfortunately, the billing cycle is already more than half way through the month, so I may have to just eat some of it which really sucks. But that’s one of the things that I’ve actually been probably more concerned about, is just am, “I storing stuff in the right way that I’m not going to get – I’m not going to run into this type of thing.” Because that’s my biggest concern is if I’m not actively in there looking at how much I’m paying for the servers every month then I could get whacked with this massive bill, and I just wouldn’t even really know it until it’s too late. And it’s like, “Okay, here’s your bill.”

Rob [01:40]: Yeah. That’s one of the dangers of this metered pricing. [?] the Google app engine. Something that I was doing for a while, when we were moving a lot of stuff around, and starting new servers and stopping, is I had a counter reminder. Every two weeks it would ping up and it would say, “Check AWS billing.” And it had a link right in, and so I would just log in and I would just look at the bill. And I knew sanity check about what it should have been each month, and so if we were a lot more than half that two weeks in, or we were a lot more at the end, then I knew we had messed something up. I did it every two weeks for maybe a year. I think I only caught something once, but it saved us probably $1,000 at the time. So that may be something you want to think about. The bigger danger – you know if it’s a mistake – because I’ve made several mistakes with AWS and accidentally purchased different things, and dropped $2,700 on some reserved instances that turned out to be not what we needed, like pretty gnarly stuff. But the bigger concern I have is, “Is this a mistake, like an accident? Or do you need that much in server costs in order for your app to run? Because that’s a much bigger issue, right. You don’t want to be paying out more than you’re making from your customers.

Mike [02:45]: Yeah. And, I mean, that’s one of my biggest complaints is just that the licensing behind everything in Azure – not everything, but in certain things inside of Azure, it’s very obscure. And so if you’re under one particular program with them – by program I mean like a licensing program. If you’re under one program with them, like you might be paying one amount. And then if you’re not under that, or if you’re on a pay-as-you-go subscription, you could potentially be paying four times as much for the exact same thing. And I’m just like, “I don’t have time to deal with this.” I don’t want to have to deal with this, but I have to. I kind of sucks. I don’t know. I have an email in to somebody at Microsoft right now to talk to them about it and say, “Hey, can we kind of move up the time table on our discussion about this.” So, I don’t know. We’ll see what happens here. But that’s kind of always been in the back of my mind that I need to pay attention to that stuff. And it’s just a distraction. You know?

Rob [03:36]: Yep. This is all the stuff that doesn’t provide any value for your customers, but you have to do it. This is like handling legal, EU compliance contracts. This is frankly handling HR when you get there. This is handling benefits and payroll, and even hiring support people, and it’s just expected [dev ops?] I see as that these are all required necessary things that if they’re not there, then it is a really bad thing. But it doesn’t provide value to your customer. It’s not about building the product. And so that’s the tough part, man, of kind of being bootstrapped, is if you had a bucket of funding you could at least hire some really good people because you could afford to pay them. And I’m not saying everything’s easier once you have that, but I see – as we started growing Drip, I really saw how having more money could make a big difference in how quickly you could move, because you don’t have to do everything yourself.

Mike [04:28]: It also allows you to ignore those problems that are at a smaller scale that if it was an extra $500 a month for three to six months, that’s not a big deal if you’ve got revenue and lots of customers to work with, because it just kind of evens out over all the customers. But when you’re still working with that really small number then it is a big deal, because you don’t really have the revenue yet to cover that and do lots of other things. So it’s a very different story. And I realized something when I thought about our episode last week where I was talking about some of the scaling issues. I went in and I looked at stuff, kind of based on that episode, and I was like, “Okay, yeah. I’ve really got to get passed this and just see what I can do to move forward, because I felt like I was turning my wheels a little bit, and I think even on the podcast it probably sounded a bit like that. So I went back and I started looking at things and I realized that what’s really happening – in terms of some of my scaling problems – is just a lack of visibility. Like I haven’t gone in and looked at certain things. It’s in the back of my mind, like that might be a problem but I’ve yet to go in and at certain pieces, looked at data, or taken measurements, or done anything like that. It’s kind of a lingering fear in the back of my mind, “Hey. You’ve got to pay attention to this, or you should go look at that.” But I just haven’t done some of that yet. And this is one of those areas where I haven’t gone to look at it and it’s in my mind as a scaling issue but nothing popped up as a problem until just now.

Rob [05:48]: Yep. I totally get it. So, for me, I don’t have a ton new this week. I’m actually flying out to Boston to speak at SaaSFest. So maybe I’ll see a few folks there. I’ve also got about three or four days of work that I’m cranking on. Something I forgot to mention last week in our goals episode was I did have a goal for DRIP revenue. And, I don’t know, I hinted around about it and didn’t say it, but I kind of wanted to say it so that it’s like on the record, and that I can revisit it next year and talk about whether we hit it. But I think we can 2x DRIP’s revenue again in 2017. This is a tall order now, right, because you’re talking large numbers. I’m talking about going from –

Mike [06:24]: Five customers to 10. Is that what you’re saying?

Rob [06:26]: Five to 10. Yeah. We’re talking about something bigger than that. So I wanted to put that out there and realized that I kind of wanted to get that on the record so we could cover it again in 12 months.

Mike [06:36]: Awesome.

Rob [06:37]: Today we have a bunch of listener questions. We’re getting some really good listener questions, and I kind of wanted to do a little theme episode where the first four really are – they’re kind of the technical side, technically related questions about software as a service. And so, our first two come from Ray Smith. And he says, “I love the show. I started listening at the very start in your first 20 or 30 episodes. Then I started a non-software business and I’m getting itchy feet to get back into software and I’ve been listening for the last couple of years. A couple technical questions.” So his first question is, “When creating a SaaS app, what are the pros and cons of having your marketing website and the actual SaaS code base combined into a single project?” I’m assuming he means like a GitHub project. Like same repo, right? Or if you’re in dot net, it’s an actual project. Stuffs not broken out. The idea is that when adding features, changes or bug fixes at the SaaS app, you can then update the sales website at the same time and push all changes in one go. So he’s saying there’s a lot of pros to it. What are the cons? Do you have thoughts on this either way, pros and the cons?

Mike [07:38]: I think both of them are a trade-off. I think that it’s perfectly legitimate to either have everything all in one project or to separate them out, and I can think of pros and cons for both of them. If you are going to integrate everything I think I lean more towards the cons for each of them, and it’s more of a, “Hey, just make sure you’re aware that these are the limitations, or that these are the types of things that you’re going to run into.” If you have them combined, then you almost need a developer to make any sort of marketing side changes, and that is not necessarily the greatest of positions to be in once you’re, I’d say, down the road a little bit. The other thing is that you are limiting the technology stack that you’re marketing site can be in. I know that a lot of people tend to go in the WordPress direction for their main marketing website, because it’s just so much easier to make changes and you don’t need a developer to do it, versus if you integrate that directly into your website, let’s say that you need to make some changes solely for SEO purposes. Well, then you’ve got all those things intermingled a little bit, and it makes things more difficult to deploy just because of the fact that you’ve got to push those marketing site changes and you have to push the app changes at the same time, and because those things are comingled you have no other choice. It’s very difficult to push them separately. Now, you can split them out into, let’s say, different projects for example, or you can deploy them into different directories and something along those lines, but it still runs into the future problem of having to bring somebody on who may be doing marketing, but now you have to have a developer go in an actually make the code changes. Those are, I would say, probably the biggest cons to it. If you do separate them, that problem tends to go away, but there are advantages to having them kind of all linked into the same tech stack. One of its which is like your signup process. You don’t have to have somebody go from one domain to a different domain to sign up. The other thing is that if you have them in separate in technology stacks, or even separate servers or sites, then you don’t have to worry about redirecting somebody from one site to another and then losing some of your tracking mechanisms for having them signup and then go to a different subdomain, for example. So I’ve run into this with Bluetick where my main website is on Bluetick.io, but then the app itself is on a subdomain. So in terms of where I have people sign up, I want that to all be done on the main marketing site, but because it’s a different technology stack than the backend application now I have to figure out, “Okay, how are they actually going to go through and signup? And how am I going to pass that information over the wall to the backend to have it do its thing so that they can login when they get to that point?” There is the cookie situation where you’re trying to track things with you various marketing tools. You want to make sure that people go through your sales funnel. But, again, those are things that you can do. You can get around them, but it’s just a lot of issues you’re going to have to be aware of.

Rob [10:29]: Yeah. I think you outlined it pretty well. I think when you first start something, I’d probably have them combined. But, boy, we hit a place where we were going to have to devote engineering time to breaking them apart. And once I brought Zack on who was doing growth marketing for us, he wanted to run all these split tests. He wanted to do things and we couldn’t. We were limited by the fact that the Rails marketing site was tied into the source code of the project, of the actual application. So I think if I were to do it all over again, I actually would probably split them apart now that I’m thinking about it. There were a bunch of shared styles. There were reasons for doing it, but I think, in the end, you’re going to want someone to be able to do stuff on the marketing site. And if you build it from the start and they’re already separated, then you don’t have to come back and try to separate it later. Because it was just hard for me to justify spending two weeks or whatever to rip it out. And, in the end, when we were acquired by Leadpages, that was one of the first things that they did. They essentially recreated the site over on a new domain and now we’re at Drip.co. It was a great move, because they do a ton of split tests. They change a lot of things very quickly. They can just iterate and go quickly. I think, overall, I would probably vote towards having two separate projects. You can have two repos, and you’re just going to want to deploy them together, or you can use some type of CMS if you want to. Ray’s second question is, “How do you handle data protection? Not security, but not losing customer data? I know you can do database backups daily, etcetera, but are there any good options for doing live backups almost instantly to an offsite location? One of my greatest fears is losing customer data.”

Mike [11:55]: This is such a technology dependent question. I mean, because if you’re running Windows in Sequel server, then you’ve got one set of answers. And if you’re running MySQL and using AWS, it’s a completely different answer. And then in addition to that, if you’re using any sort of key value parastorage from either AWS, or Azure, or Rackspace, or any of those other providers, then you have this secondary set of data that is not in a database, but it is important to have that along with your customer data. I don’t know how to best answer this just because it does depend on those things.

Rob [12:30]: I actually think the answer for any relational database is going to be the same. And I think your right for key value stores like [Retis?] or whatever, I would argue that most people use those for caching, and that it you don’t necessarily need to back them up unless you’re using them to perpetually store things.

Mike [12:45]: It depends on what you’re doing there though. In Bluetick, for example, I store copies of header information from emails that I’ve synchronized from their mailbox.

Rob [12:54]: Okay, so you store them in [Retis?] or in a key value store?

Mike [12:56]: Yes.

Rob [12:57]: Got it. So then that you’d have to back up. Now is that writing to disk every minute or two and then you’re sending that off to the equivalent of S3?

Mike [13:04]: It’s synchronized. It’s the equivalent of S3.

Rob [13:06]: Okay.

Mike [13:07]: Yeah, I would say it’s kind of like that. The cache doesn’t go away when the machine restarts or anything like that. It’s just a long-term data storage. It’s basically like a non-sequel database is more or less the best way to describe it.

Rob [13:20]: Right. I think his concern is – he says, “I know you can do daily backups, but can you do stuff that’s more up to the minute – instant backups?” And any RDBMS has log files, right? And if you’re putting those log files to multiple drives – now maybe they’re not offsite instantly – but you can basically do a point-in-time restore using those log files, right?

Mike [13:40]: Yeah.

Rob [13:40]: And that should work for MySQL and Sequel server and PostgreSQL and all those.

Mike [13:44]: Yeah. That’s generally how you would do it. For the longer term storage stuff, even in AWS or Azure there’s multiple ways of having that data be sent out. Usually you can use some sort of location specific storage where you’re going into a particular region of the country, or a specific data center, or something along those lines. The other thing that you could look into is having essentially a multi-site fail over. Now, that’s not something that you want to get into on day one –

Rob [14:11]: Yeah, you’re way out ahead of Ray.

Mike [14:12]: Yeah.

Rob [14:13]: Ray’s talking about whether to have his marketing site with his app at this point.

Mike [14:19]: Yeah.

Rob [14:19]: I think that you wouldn’t even want to think about that at this point. I think, “A” if you have two hot swap databases – or not hot swap – but you have a main database, and then you replicate out to a second fully developed database, a backup that’s essentially hot and sitting there at any time, that’s you’re instant offsite backup, in essence. Or if you put it in another zone or something. That’s probably the safest way to do it. But I don’t think you need that at the start unless you’re dealing with really critical stuff. I think having your log files put to multiple drives, and written out to S3, and then having a daily partial backup, and then it’s a weekly full backup. This is the standard stuff that DBA’s would do. That’s going to get you a lot of protection up front. You don’t want to over-engineer your SaaS app when you have 20 customers or whatever. And then I think down the line, at some point, you are going to want that fail over in case something crashes. But a lot has to happen for all of that to be gone.

/// [15:13]

Mike [15:12]: Yeah. And most databases that I’ve seen you can go down to like an hourly backup that’s just a partial backup, and then you do a daily backup, and then you do a weekly backup. So you take your weekly’s, you put them offsite, and then you do your daily’s, and then your hourly’s are based off of your daily’s. So at most you would have to put in – let’s say it fails on a Friday – you’d have six days’ worth of daily backups to apply, and then you’d have however many hours of hourly backups to apply. Which is not, you know it sucks, but it’s not a huge deal, and you’d at least have that hourly snapshot.

Rob [15:43]: Right. And Ray, that’s advice from two guys who are not DBA’s, who basically know just enough to be dangerous.

Mike [15:50]: Well, I actually know more than a lot of DBA’s that I’ve met. I do agree with Rob that all the stuff I started talking about with being able to store your data in multiple geographic locations, I wouldn’t even worry about that stuff. I would just go with the hourly backup at the most, and then just work from there. If something crashes, if it’s some customer data, it’s probably not that big a deal. Especially if you only lose like an hours’ worth.

Rob [16:14]: I don’t know that I’d say not that big of a deal. I do think it will be a big deal if it happens. Just the odds of it in the early days when you have a small amount of customers, it’s just not that likely to happen. And so, you’re right, you need these backups. You want to be able to restore from them. You don’t want to lose data. But there’s always this knob you can turn of how far do you go when you only have a handful of customers.

Mike [16:35]: Right. The one thing I would point out – because I’ve seen this happen to somebody before – is test the backups. Make sure that you can restore them, because I’ve seen somebody’s business be completely destroyed because they thought they were doing backup and they weren’t, and their backups didn’t work. They not only lost their entire database, but they also lost all of their customer’s information, and the way that they get in touch with all their customers. It was all gone.

Rob [16:58]: Pretty crazy. I remember that. Our DBA does that once a month. Takes all the backups and restores them onto a server and queries it and shows us the results. It’s kind of nice. Our next question is from Roger in the UK. And he has a question about a SaaS app accessing a corporate database. So he says, “I have an idea for a product which I’d rather implement as SaaS rather than the client installing the application, because the software’s complex, it’ll be updated regularly, and therefore, the client installing it would not be practical. However, it would require access to the corporate database of the customer. How easy is it to get a client to provide the database name, user ID, and password to a SaaS app so it can access their internal relational database?” Mike, did you cringe when you read this? There’s just no chance – the answer is there’s no chance ever that this will work. No chance they’re going to give it to you. Not only are they not going to give it to you, even if they created a read-only login. You’d never make your database to the outside world. You don’t open the firewall ports to it. So, I think it’s probably more useful to talk around what are the other options, because you’re not going to have any customers if you do it this way. Do you have other ideas, maybe, for how Roger could approach this? And if he needs access to their data, how he can do that? I also think we should probably discuss whether it actually needs to be a SaaS, you know, or they need to perhaps install it inside their firewall.

Mike [18:22]: I think that was what kind of came to mind for me. You almost need this piece of software that’s in their environment that’s running, that is separate from the database. And the closest thing that I’ve seen to this type of model is where you’re essentially providing somebody a virtual machine that they can put into their infrastructure that acts more as an appliance than anything else. And that’s probably the closest thing that I’ve seen. But I don’t know as you would get somebody to hand over the database name and credentials and stuff like that, unless it was to go into something like that where it is reaching in, it’s accessing the database, but if it’s an existing database, that’s a totally different story. I’m getting the impression from the way that this question was phrased that this is acting on an existing database, and it’s providing statistics and queries and additional indexing of the data that’s in there, which is a different type of problem that you’re solving then if you simply need the customer to install a database in order to run your app. So those, I think, are two very, very different situations. Now if it’s the first one where you’re trying to analyze their existing database, you really need to have some sort of a downloadable piece of software. And if they want the latest features you’re going to want to have them update.

Rob [19:34]: Or you could build and auto-updater in it, right? Something that helps manage that, and it allows them to pretty easily update. It depends on how complex it is, but this is not out of the realm of – like .Net’s gotten pretty good at being able to auto-update desktop and server apps.

Mike [19:48]: That’s problematic though just, because of the issues that you’re going to face with like user access control in Windows. It’s actually gotten much more difficult to do those types of things.

Rob [19:57]: Yeah. When I say “auto update,” I don’t mean in the background.

Mike [20:00]: Okay.

Rob [20:01]: I mean that it pings the add man and it says, “Hey, it’s time to update.” One-click update. Maybe that’s what I meant.

Mike [20:05]: Okay. Yeah.

Rob [20:06]: That is what I meant. I meant much more of that, where they don’t have to download this big zip file and read a bunch of instructions and run command line things. They click the button, and as long as you give it the user access control stuff, it’ll go out and download it, and verify, and install the MSI, or whatever.

Mike [20:22]: Yeah. Simplistic updated –

Rob [20:24]: There you go.

Mike [20:24]: – versus auto updating.

Rob [20:26]: Yep. That’s a good point. The other idea I have here is, I don’t know to what extent Roger needs his code to be able to access their database, but it just depends to what extent. If he needs to run queries across millions of rows, then yeah, he really does need direct access. But if not, and if you’re just pulling users out to look at something or you’re just pulling different things out, you could either ask the corporations to build like a small rest layer – like a little API on top that you’re hitting from the outside – or build it for them. If all of your customers are going to be running Sequel server and they’re all going to be paying you a tremendous amount of money – let’s say the average contact value is $50,000 a year, or $100,000 a year, then build a single rest API layer, and you know that it’ll run on Sequel server. And if they’re running Sequel server, they’re probably running .Net so you build it in C#. And if you’re on PostgreSQL then maybe you build it in PHP or in Python or Ruby. But you pick a language where you almost lay something on top of it, and it accesses it and then is a couple to communicate it, like as a “conduit” is probably the best word. They would still have to install that piece but it’s a server piece that’s just communicating out through, obviously, a highly secure mode of communication, encrypted and SSL and all that stuff.

I still think you’re going to run into people who don’t want to install stuff on their servers but, again, it really depends – without knowing more about the idea. Because people do install monitoring software on their servers. They’ll install NewRelic, or they’ll install Redgate. So it’s not that it never happens. It’s that you need to “A”, get the credibility and, “B”, really tell people what they’re installing, and what it’s going to do on their servers. And if it’s going to provide them a lot of useful information, I do think that you can get some people to agree to do this.

Mike [22:04]: There’s a big difference between installing something like a server performance monitoring software, and something that goes into the core of the database and pipes any sort of data outside of the local network. That’s a big problem. Those are two entirely different things, and any DBA is not going to want to do that.

Rob [22:21]: That’s right. Any CTO won’t want to do that, unless the value proposition is there and it’s worth it. I mean, that’s the thing. Without knowing what this idea is, are there other companies that are already doing this, and doing it successfully, and it’s the standard for this type of application. What if it’s offsite backup software? Yeah, they’ll probably do that, right? Because that’s the whole point. It needs to back it up, it needs to send it off site. But you’re right, if it’s a time tracking app, then the odds of that are much, much less.

Mike [22:52]: Yeah, but even you get to a certain level, or certain scale, with the type of customer that you’re targeting, they are going to want to be able to control those things in house. They’re going to want to install them themselves. And even with an offsite backup, there’s companies that do provide appliances like that and they just buy multiple appliances and they point them on opposite sides of the country and it just propagates the backups from one side of the country to the other. And the companies are willing to pay tens of thousands for each of those appliances and it maintains in their control. They don’t necessarily have credentials to all the core stuff inside of it, but it’s an appliance. They own it. They can do whatever they want with it, and they control where the traffic goes. It’s not like it’s reaching out to some external service that they need to completely control all the traffic going into it and out of it.

Rob [23:37]: There you go, Roger. You heard it here first. If you’re building an offsite backup engine, we’re recommending using an appliance, or at least having a better chance of doing it. Now I think that depends if your certain clients are willing to do that. Certain clients of certain sizes. I think if you talk to a small or medium-sized business – let’s say you talk to a dentist, who has a couple servers running something. Or you talk to a 30-person law firm who, definitely has IT folks and definitely has servers, but are they going to be willing to pay $20,000 a year for an appliance? Or would they perhaps prefer there to be a less expensive option for getting offsite backup. So that’s where I think if you choose your customer wisely, you could potentially find folks who are willing to deal with some of these different options we’ve thrown out. Our next question – it’s our fourth technical SaaS question, and then if we have time, we’ll move onto another. This one is from John Buford. And he says, “Hey guys. In episode 311 with Derek Rhymer, you mentioned “SaaS quality” several times. Can you describe how you measure or quantify SaaS quality? Is it based on the code base, or is it more aligned with overall business in terms of MRR, low churn, big list size, etcetera? Are the differences in quantifying SaaS quality as viewed from a seller of a SaaS app versus the buyer?” This is not a common term. I just happen to throw it out and say [?] is a really high quality app. And all I meant by that was the code base was pristine. It had a tone of test coverage. Zero or very, very few known bugs, modular code, really good coding standards, the deployment and architecture are all set up. Just everything you would want as a developer from a code base was there. In addition, it looks really nice. The design is really nice. It just feels like a high quality app. That’s all I was referring to. I don’t know if anyone else’s definition would be the same as that, but I was not talking about financials, or churn, or big list or anything like that. It really was specifically from more of the technical side of things. Moving on to our next one. We have a question from Chris [Cottom?]. And he says, “Hey guys. You’re both now working on businesses that deal with tons of email, so maybe you’ll have some insight into this question. Do you have any tips for reengaging with an email list, or with leads with whom you haven’t communicated in a long time?”

Mike [25:51]: Yeah. I think that if you’re trying to reengage with people then you’ll probably want to, I’ll say, prep the email engine a little bit, and have at least some idea of what it is that you’re going to be sending them down the road. So let’s say you got a couple thousand email address that you haven’t touched base with in, call it 10 months, for example. In a situation like that you probably want to map out what it is that they originally signed up to the list for, and try and translate to say, “Okay, we’ll how do I get back on track with that? Where did things go wrong? Why did they go wrong? And how do we get back on track with that?” And map out the next half dozen emails that are going to be sent. Now, I don’t think you need to write all the text for each of those six emails, but you at least need to have a conceptual level of what the bullet points are that you’re going to cover over the course of those next six emails, and when you’re going to be sending them. Because the last thing you want to do is send out an email to those people to kind of reengage with them and then drop off the face of the earth again. I would start out by doing that, figuring out what it is that you’re going to say to them. And then, in addition, the first few emails that you send out to them to kind of reengage with them, you probably want them to be a little bit shorter than you otherwise would. Try and provide some value up front. You don’t want to just launch into a sales pitch, for example, because it’s been a while and they haven’t seen emails from you. You don’t want to lead with a sales pitch at that point.

Rob [27:10]: Yeah. I think what you said was good advice, and I think you want to provide a lot of value in that first one. This is a make or break moment, and you’re not going to get most of the people back, but you really have to be sure you explain why you’re contacting them; why they were originally on your list. And then give them something free that should otherwise cost money. Or give them a really great tip. Or give them something – depends on at what scale you’re doing this. Are you doing this to 10 people? In which case I’d do some very custom something or other. Review their website or something. And if you’re doing it for 10,000, you can’t do that, but you can give away an e-book or video course or something that is of quality to basically apologize and get them back.

Mike [27:47]: It gives them a reason to stay on your list, is really what that is.

Rob [27:50]: Yep. That’s right. There’s a whole other topic. Originally when I read this I thought it was for reengaging people who are on your list but who just haven’t opened emails in a while – kind of people who have disengaged. But there’s a really good workflow for this in the knowledge base. We go to KB.getDrip.com and search for I think it’s like “reengagement.” There’s workflow blueprints there. There’s only maybe 20 of them, so it’s easy to flip through. In essence, it sends them an email and it just says, “Hey, I’ve noticed you haven’t opened emails in a while. I’m going to unsubscribe you, basically, and if you don’t want to do that, click this link.” And you get a small portion of people to hang around and reengage a bit. The good part about that is you’re actually increasing your sender reputation by doing that because, these days, Gmail and Yahoo and these ISP’s, they look at the domain that it’s coming from, and if your open rates are crappy then they start penalizing you and sending you either into spam or into the promotions tab. So keeping that high is a good thing. In addition, it can cut down on your costs. If you unsubscribe those people, then you’re paying your ESP less money because you have fewer subscribers but your open rates will be a lot higher. That’s a good question. Thanks for the question, Chris. I hope that was helpful. Our last one is from Ali, and it’s a question about whether email lists are really relevant/effective in the US. He says, “You’ve mentioned email lists for marketing and sales throughout many episodes, and it made me wonder are things really this different in the US? I’m from Saudi Arabia. If I would ask my colleagues who work in sales and marketing about using email lists, they would not even entertain the idea – not even as a last resort. From my experience, if you send unsolicited emails – and “unsolicited” is the key here – unsolicited emails they will end up ignored or deleted, and if you persist, your domain probably will be blocked altogether. It’s all about knowing the right people in a [?] organization” and some other stuff. It feels like maybe he’s confusing kind of cold outbound email versus spamming, versus opt-in marketing lists. You have some thoughts on this, Mike?

Mike [29:42]: Yeah. Well, as you pointed out, the whole difference between unsolicited emails and things that people have opted-in to because they want to hear more about a particular topic. That right there is the fundamental difference between those two things. I will say that there is some semblance of certain types of cultures would probably shy away from certain sales techniques. And you can even translate this not just into cultures, but different groups of people, one of them being developers. Developers tend to not want to call people on the phone. So those type of people will tend towards email lists and other types of marketing efforts which don’t involve them getting on the phone and actively talking to a prospect versus that email list. It’s much easier for them. And then if you take that the other direction, you can say, okay, what about an inside sales rep. They’re used to being on the phone all day. So their natural inclination is to pick up the phone and call people. I don’t think that it’s a whole lot different whether you’re talking about different groups of people, or different cultures, they all have their natural tendencies to do one particular thing. But that doesn’t mean that it’s always the right thing for every situation. You do have to take it into context a little bit. But the fundamental thing is just unsolicited versus opt-in.

Rob [30:56]: Right. That’s a big one. That’s kind of building that prelaunch mailing list. Now there is this whole other branch of essentially B2B cold email. So there’s the CAN-SPAM Act in the US. And, obviously, if you’re sending bulk unsolicited email to consumers, that’s illegal. And there’s no way around it. I’m pretty sure if you send individual cold emails pitching a service or something, that that’s illegal. I don’t know enough about cold email, because we don’t allow it at Drip. But I do know that B2B there is a carve out in CAN-SPAM where if you’re sending like a direct, one by one emails from one business to another soliciting stuff — there are companies like LeadGenius and LeadFuze – where I’m an angel investor – and that’s a little cottage industry that’s formed around sending cold email outbound one at a time to prospects. And that has had success. There are entire books, like “Predictable Revenue” that are written around this concept. You probably have some thoughts on this, Mike, having worked on Bluetick now for the past six to 12 months.

Mike [31:55]: Yeah. I looked into this pretty extensively because that was one of the questions that came up early on. Not only did I have it, but there were people who asked me specifically. This is more applicable directly to the US because of the CAN-SPAM Act, but there are three general classifications of email. The first one is the commercial one. Most people are more familiar with this because they think if of it as the spam laws that people are running afoul of. So there’s the three different categories. There’s the commercial, and then there is the transactional emails which is if you purchase something from someone, they can send you a receipt; they can send you follow-up emails, let’s say, for you to download something. It’s generally the emails that you would send to somebody in the course of doing business with them. And then there’s this third category which is called “other.” And the documentation that I saw literally called it “other”, which is interesting because they don’t put a very good definition on any of them. They specifically say that for commercial, you’re emailing somebody in an effort to sell them something. But if you, let’s say, send somebody an email and ask them, “Hey. Can we set up a meeting? I want to talk to you.” That’s not considered a commercial email. That falls into “other.” Pretty much anything that’s non-transactional, or isn’t directly pitching something for somebody to purchase, falls under “other.” So it becomes this very grey area where you get into that situation and it’s like, “Okay, well, this one might be spam. This one might be considered commercial, this one might be considered “other.” Transactional is the one that’s really well defined. The other two are not. And it does depend, I think, a little bit more on whether or not you’re emailing with a business, versus an end-user or consumer, so to speak. But there’s a lot of grey area there that people work with, which is kind of the reason why the ESP’s are the ones that tend to be the people who are enforcing that – not the Google’s of the world or other mailbox providers. They don’t necessarily care as much, because if you get your domain banned, they’re not the ones who suffer for it. But with the ESP – you’ve run into this with Drip – it’s your IP addresses that are at risk. Not the customers. That’s really why those ESP’s really crack down on those, and really want to make sure that you are not sending bulk spam because they’re the ones that are penalized for it and all their other customers. There are revenues at stake.

Rob [34:09]: Yeah. That’s right. You look at MailChimp or Drip and we have entire massive algorithms. I won’t go so far as to say their AI, but it’s machine learning stuff that’s looking at listed or being imported. It’s looking at different signals that people signup behaviors in the app. Certainly the open and the click metrics and spam complaints. We have this whole network of we’re approaching a couple dozen signals that we look at over the course of the lifetime of a customer, all the way from the first time they entered that form all the way through their sending and we flag a lot of people and manually review them, and we always try to educate, to try to help the customer understand what they’re doing. But when you have IP’s and sending domains that you’re worried about, this is the stuff you have to have in place or else, as Ali originally mentioned, if you were sending unsolicited, then the stuff will get marked as spam and then your IP’s get dinged and then you can’t get into people’s inboxes any longer.

Mike [35:01]: Right. According to the official guidance from the CAN-SPAM Act, if you go over to FTC.gov, they’ll spell out certain things. They kind of boil it down into seven points. One of them is don’t use false or misleading header information. Don’t use deceptive subject lines. You have to identify it as an advertisement. Telling people where you’re located, giving them a capability of opting-out of future messages. But again, these are for bulk emails. And if your sending individual emails, it kind of falls into this very, very grey area. If I send out 10,000 emails – or even, let’s say 100 – it’s a very different story than if I send out the same email to 35 people and I individually click send on each of those. It’s treated differently. I also think that because of all the grey areas there, you’re in a different world when it comes to interpretation of what it is that you’re doing. And if you were to send out 10,000 of them you’ve got 10,000 possible sources of complaint. And that kind of puts you in a much higher risk category, I would say, then if you’re just emailing a few people here and there. Or even just 1,000 people but it’s over the course of a couple of months or a couple years or something like that. It’s a very different story.

Well, thanks, Ali. I hope that answers your question. And I think that about wraps us up for today. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690. Or you can email it to us at questions at startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Outta Control” by MoOt used under creative comments. Subscribe to us in iTunes by searching for ‘startups’ and visit startupsfortherestofus.com for a full transcript of each episode.

Thanks for listening. We’ll see you next time.