This is chapter 2 if you’re here for the first time — please read: Chapter 1 ←
Ok, so — the lawyers moved quickly, we signed the contract, then wired 80% the acquisition price into escrow (the contract stipulated a 20% holdback, to be paid 30 days after the closing). The order of operations was to be as follows:
- Escrow agent confirms receipt of our money
- Live transfer of assets at 10:30 AM EST, on July 17th
- After we confirm receipt of all assets, we email the escrow agent and approve the release of our funds to the seller
This was ALL meant to happen in a matter of hours. Our list had been given to the seller days in advance and it was a list of around 15 passwords, transferring some accounts, and we’d be on our way.
10:29 AM: just Ben and Joe, for now. Engineering team on-call, waiting to dig into the code repository.
10:34 AM: Joe texts the seller, no reply.
My guess was the seller mixed up time zones as they were not on EST. So we said we’d wait until the afternoon and do it then.
1:30 PM: Joe texts, calls & emails (with tracking!) the seller, and no reply or opens.
At this point, we think that the whole thing is a scam, the escrow agent and seller tricked us.
2:02 PM: Seller surfaces!
What a relief. The first order of business was to begin handing over the key accounts. MailTag GSuite, Stripe, MailChimp, Zendesk… etc.
Zendesk, the customer support platform was the first grenade thrown at us. We log into it, and the account is frozen… I think to myself, “that’s odd, I thought he took care of all the pissed off customers”.
We go to the only non-frozen part of the website, the Billing section! How convenient!?
We update the credit card information. Our card immediately gets hit for 8 months of service charges, and immediately comes back to full function. We go to the customer support area to take a look…
It was a blood bath. What we found were 1,302 unanswered customer inquiries. That was more than the total number of paying users on the platform, we’ve got a major league problem here.
We start reading random inquiries, everyone’s messages are about some combination of:
- the product not working
- wanting to cancel their account
- wanting a refund
Joe and I act immediately, we knew the most important thing at that moment was trying to clear up any customer issues. This was not going to be a fun exercise — we’d lose A LOT of customers.
Our message to the users was clear:
We’re sorry. As new owners, we are making a full commitment to the customers and product — please just give us a shot.
We showed the users a lot of love, and it was genuine — we needed them.
Some replied with very nice messages wishing us luck, some wished us luck and expressed their desire to cancel their accounts (which we did), and others were incredibly mean/rude, they wrote emails to us full of venom.
By the next morning, we’d lost half of the paying user-base and began to peel back the onion on the misrepresentations of the deal.
We were under the impression that the user-base was loyal (total lie), and growing organically (sort of true, we’ll get to that eventually). We were promised there was no backlog of customer support issues — which was true because when your account gets frozen, there are 0 accessible inquiries! Ah!
At this point — we’re frustrated but still amped up from all of the drama. We were excited that we were rolling up our sleeves and getting into the trenches. We learned how to admin the systems (we got really good at issuing refunds via Stripe!).
There were still some lingering customer issues, and Joe was in the zone replying to them… I moved onto the product, and started digging into some stats on the Chrome Store where I noticed a warning on the dashboard.
I checked the email that had the Chrome Developer Account connected to it. An email sent by Google the day before the hand-off, the email had been marked as Read.
The non-technical translation of the above email is: Your product didn’t make the cut, collect your things and go home. MailTag is going to be obsolete very soon.
A bit more technical now: in order for Tracking, PING’s, and Scheduled Emails to work — Google grants our product access to certain information in people’s email accounts.
The different types of information are categorized by what information we need to perform the functionality. These are referred to as Scopes, for example:
- gmail.compose: this enables MailTag to add the tracker to the email body
- gmail.send: this allows MailTag to send an email on behalf of the authorized user
- gmail.modify: this enables MailTag to manage the user’s draft folder (this is used in our Schedule feature. We clear the scheduled email from the Drafts folder once the users selected time activates
- gmail.readonly: this enables MailTag to read the inbox thread ID to send reminders on behalf of the user (this is what PINGs sequencing is)
When users onboard MailTag, they agree via Gmail OAuth to share this access with us — and voila, like magic — it all works. With these permissions taken away from us: there is no more product, just some pretty website design. We could lose it all if we didn’t get Google’s decision reversed.
I reviewed our situation with our Engineering Team Lead and he felt if we applied, with supporting details — we’d have a shot at get approval from Google eventually, but no guarantee. The product was still working as our access to the scopes had not been shut off… yet.
I began working on the application for Google with one of our engineers and turned it around within a couple of hours. Now we had to wait for Google. In the meantime, I tasked the team with finding me a “Plan B”, just in case…
I called Joe:
Don’t you think this falls under “anything else we should know about?” question we asked him 3 or 4 times during our diligence period. This guy is a total liar.
It’s really bad, I’ve been reading about this Gmail OAuth issue. I was sure that MailTag had passed through the verification process for this as it worked well and Google never gave us that red WARNING signal. There are other developers out there talking about 3–4 months of wait time with Google, along with Google requiring them to do 3rd party security audits, costing up to $75,000 per year from a group of pre-approved security firms. And a handful of shuttered companies from this.
More about the Gmail OAuth API crackdown, here.
Good news: 80% of our funds were still sitting in escrow. It gave us some time to get a clearer picture of the mess we’d walked into. Along with some leverage, hopefully. We’d spend the next 36 hours going through things and felt confident that we had a clear handle on what was going on, what happened and what we needed to do next.
Bad news (for us): After the old team had patched that issue that I (and many others) had prior to us acquiring MailTag, I installed the extension and was greeted by a lovely note from our friends at Google:
Any new user who installed MailTag was seeing this message as they on-boarded. Our API access had been revoked, and the only people who could use MailTag was the small number of users we’d saved in our customer service exercise the first 2 days.
How about that plan B guys? You’re working this weekend.
My next phone call was to our lawyer. We got screwed and wanted our money back.
Stay tuned for the rest: hookers, lawyers and blackmail… Oh my.
Ready for Chapter 3? Here you go →https://blog.mailtag.io/i-want-my-money-back-and-the-big-gamble/
Supercharge your sales process with MailTag.
Track ✉️ Schedule 🕒 Automate 🚀