Common problems with new email tools

Recently, a client reached out to us expressing frustration with the RAG (Retrieval-Augmented Generation) application they had implemented for customer support emails by a different AI agency. Despite high hopes of increased efficiency, they were facing some significant problems: The RAG model frequently provided wrong answers by pulling information from the wrong types of emails. For example, it would respond to a refund request email with details about changing an order - simply because those emails contained some similar wording. Instead of properly classifying the emails by type and intent, it seemed to just perform a broad embedding search across all emails. This created a confusing mess where customers were receiving completely irrelevant and nonsensical responses to their inquiries. Rather than streamlining operations, the RAG implementation was actually making customer service much worse and more time-consuming for agents. The client's team had tried tuning the model parameters and changing the training data, but couldn't get the RAG application to accurately distinguish between different contexts and email types. They asked us to take a look and help get their system operating reliably. After analyzing their setup, we identified a few key issues that were derailing the RAG performance: Lack of dedicated email type classification The RAG model needed an initial step to explicitly classify the email into categories like refund, order change, technical support, etc. This intent signal could then better focus the retrieval and generation steps. Noisy, inconsistent training data The client's original training set contained a mix of incomplete email threads, mislabeled samples, and inconsistent formats. This made it very difficult for the model to learn canonical patterns. Retrieval without context filtering The retrieval stage wasn't incorporating any context about the classified email type to filter and rank relevant information sources. It simply did a broad embedding search. To address these problems, we took the following steps with the client: Implemented a new hierarchical classification model to categorize emails before passing them to the RAG pipeline Cleaned and expanded the training data based on properly labeled, coherent email conversations Added filtered retrieval based on the email type classification signal Performed further finetuning rounds with the augmented training set After deploying this updated system, we saw an immediate improvement in the RAG application's response quality and relevance. Customers finally started getting on-point information addressing their specific requests and issues. The client's support team also reported a significant boost in productivity. With accurate, contextual draft responses provided by the RAG model, they could better focus on personalizing and clarifying the text - not starting responses completely from scratch.

I've been setting up a new business management platform recently and stumbled across a set up problem. The system has built in unsubscribe functionality which sounds great but there are problems with this blanket unsubscribe. When someone unsubscribes to stop receiving marketing emails, the system completely locks them out of ALL emails - including the ones they must legally receive. Here's the problem: Your customer opts out of your newsletter but now they can't receive their invoices, contract updates, or renewal reminders either. This creates a mess with multiple regulations: PECR (Privacy and Electronic Communications Regulations) - you need proper consent or soft opt-in for marketing, BUT transactional emails don't need this consent Consumer Rights Act - customers have rights to receive purchase confirmations and contract information E-commerce Regulations - you must provide order confirmations and delivery information Consumer Contracts Regulations - require proper notice of contract changes and cancellation rights GDPR - lawful basis for processing differs between marketing (consent) and transactional emails (contract/legal obligation) What this looks like in practice: ·       Your client unsubscribes from your weekly tips email (withdrawing marketing consent) ·       Three months later, she misses her subscription renewal because the system blocked that contractual notification too ·       She complains she never received notice, disputes the charge, and leaves a negative review ·       You're left explaining why you couldn't send her the legally required notifications Popular platforms doing this include: GoHighLevel (and its white-label versions), Kajabi, Kartra, and Zenler - though there are others. The fix is simple: Your email system needs to distinguish between marketing emails (needing consent or soft opt-in under PECR) and transactional emails (sent under contract or legal obligation under GDPR). Check your platform settings today. Can someone who's unsubscribed from marketing still receive their invoices and contract notifications? If not, you've got a compliance gap that needs fixing.

I’ve watched SendX go from a few million to 300M+ emails/mo, and there are 4 things from that journey I wouldn’t wish on my worst enemy 👇 1. Email sending engines that keep you blind at the exact moment you need clarity Nothing tests your sanity like watching deliverability dip and having no way to break it down by domain, IP, sender, or customer. You’re left guessing which part of the system is sinking the rest. That kind of blindness turns small issues into platform-wide messes. 2. Needing 50 tools to investigate one deliverability issue Every ESP operator knows this pain: logs in one place, alerts in another, blacklists somewhere else, customer complaints in a ticket, bounce spikes in a spreadsheet, and half the story buried in someone’s Slack DMs. You go in circles for hours, and the root cause still hides behind a missing piece of context. 3. Team bloat disguised as “growth” Nothing feels more pointless than hiring two extra deliverability people just so they can chase bounces, rotate IPs manually, warm domains like sourdough, and sift through logs because the system can’t automate anything. It’s not growth. It’s tool-induced inflation. The kind you get when your tech stack hasn’t evolved since 2014. 4. Watching costs balloon, without anything getting better Legacy systems bleed you slowly. You pay $600–$800 per million emails for basic sending. You buy IPs that don’t fix anything. You pour money into warmups, reputation tools, and “deliverability add-ons” that barely move the needle. In the end, the fix was simple: build a tool for modern ESPs that want scale and visibility. → We built SendPost. And now it's open for every high-volume sending ESP that doesn't want to live the nightmares. SendPost gives you real-time insight into every IP, domain, and sub-account — plus live provider-response data and AI health alerts that keep deliverability from drifting. If you'd like to see it, DM or leave a comment.

Most sales email problems don’t start overnight. They build up slowly. - Your bounce rate creeps up - Your replies drop - And one day, everything lands in spam That’s why we make sure deliverability problems never start in the first place. Here’s how we do it for every client: → Secondary domains We create a big list of secondary domains and check availability with GoDaddy's bulk checker. Making sure there are always backups ready, depending on the volume. → Warming protocol This varies by your sending solution. But it's most important to have the increment as low as possible and run for at least 14 days. You don't need a 'premium' warmup solution. Instantly.ai's one has been more than enough for us. → Verification We clean every lead list before sending. No invalid or risky addresses. You don't need an expensive tool for this. Just one that can catch spam traps like Bouncer. → Sending limits Slow ramp-up options are your best friend in the start. We always gradually increase the volume until it reaches what's required. → Reputation monitoring Having an idea of the status of every domain is a must. Google Postmaster, Microsoft SNDS, MxToolBox, and infra providers that give you admin access to your accounts are non-negotiable. If something dips, we catch it early. The goal isn’t to fix deliverability. It’s never to let it become a problem. Sure, you can never make them disappear completely. But it makes it significantly harder to fix if you're not doing this stuff right.