Last month I landed a project worth around $800 for an SMS automation. I was genuinely excited because the scope was clear, the client seemed really engaged during our calls, and I knew exactly how to build it. I spent about a week getting everything set up, staying up late some nights because I wanted to get it just right. Built it, tested it obsessively, deployed it. Everything worked perfectly. The client started using it immediately and I remember feeling that little rush of accomplishment. Finally. A project that landed well. Then three days later, complete silence. The automation was still running in the background, no errors in the logs, everything technically functional. But nobody was touching it anymore.
I waited a few days thinking maybe they were just busy, but the knot in my stomach kept growing. I reached out to the client after a week, trying to sound casual but honestly feeling a bit panicked. I asked if everything was working okay, if they needed any adjustments, if there were bugs I somehow missed during testing. They responded with something that I still think about regularly. "Yeah, it works fine. We're just not really using it." That was it. No technical issue, no complaint about the interface, no request for changes. Just complete indifference. I didn't know what to do with that response. The automation worked. That was supposed to be the hard part, right? So why didn't they care?
I couldn't let it go. That night I started going through my past projects, just scrolling through old invoices and deployment logs out of morbid curiosity. Maybe this was a one-off thing. It wasn't. Out of about 50 automations I had built over the past year, maybe half were actually being used regularly. The rest were like this one. Technically functional but practically abandoned. Some clients were still paying monthly server costs to keep them running even though nobody in their company had logged in for weeks. And the part that really got to me was that they all worked. There were no bugs, no crashes, no data loss. The code was solid. So what was I actually doing wrong?
A few weeks later I had a routine check-in call with a different client, someone whose automation was actually thriving. Their team had fully adopted it, they were seeing real results, and they kept asking me to add more features. I decided to just ask him directly. Why do you think your team actually uses this when other clients seem to forget about theirs after a few days? He didn't even have to think about it. He just said "Because it fits how we already work. Your automation didn't make us change our process. It just made our existing process faster." That sentence completely rewired something in my brain.
I had been building isolated tasks this whole time. Cool, functional, technically impressive isolated tasks. But I was never thinking about the actual messy, real-world process they were supposed to fit into.
Let me give you the clearest example of how badly I was missing this. I built an SMS automation that was supposed to personalize messages by using the lead's first name. I built the whole workflow, added all the logic for pulling the name from the database, tested it with sample data where I made up names like John and Emily, and it worked beautifully. Every test message came out perfectly personalized. Then a few days later I was just randomly checking the actual messages going out to real leads and they all said "Hi there, thanks for your interest in our product." Every single one. Generic. Impersonal.
I immediately went into panic mode. Checked every node, every variable, every data transformation step. Nothing was broken. Everything was working exactly as coded. Then it hit me. The issue wasn't in my automation at all. It was in the web form that was capturing leads before my automation even started. There was a name field, sure, but it was optional. Most people were just typing in their email and hitting submit. They were skipping the name entirely. So my beautiful personalization automation was working perfectly, dutifully pulling data from a database field that was almost always empty. The problem wasn't the code I wrote. It was that I never bothered to look at what was feeding data into my system in the first place.
That's when I started approaching projects differently. Now before I build anything, before I even open n8n or start dragging nodes around, I spend time mapping out what I call "look left" and "look right."
Look left means really understanding everything that happens before my automation triggers. Where is this data actually coming from? What format is it in? What fields are required versus optional? Is the marketing team's funnel actually set up to capture what I need?
Look right means understanding what happens after my automation finishes its job. Who actually receives this data? What do they need to do with it? What's the very next step in their day?
This sounds incredibly obvious when I type it out, embarrassingly obvious actually, but I genuinely wasn't doing it before. I was treating each automation like it existed in a perfect vacuum where data magically appeared in the right format and magically got used exactly how I imagined.
Here's what that shift looked like in practice. A client came to me and said they wanted a chatbot for their website. Old me would have just built a chatbot. New me asked: "What does your sales team actually need to know before they pick up the phone to call one of these leads?" The client paused and said: budget and location. Those two pieces of information determined whether a lead was worth pursuing immediately.
So instead of building a chatbot that had nice pleasant conversations and collected email addresses, I built one that specifically extracted budget and location during the natural flow of conversation. Then it automatically routed qualified leads to the CRM with those fields already filled in, and marked them as hot or warm based on what they said. Same technology, completely different outcome. The sales team actually started using it within days because it wasn't giving them more work. It was saving them the 10 minutes they used to spend on each call asking basic qualifying questions.
I also realized I was only building for binary outcomes. Qualified or not qualified. Yes or no. But that's not how actual business works. Most leads aren't a clear yes or no. They're interested but their boss needs to approve the budget first. They love the product but can't implement anything new for two months.
So I started building a third route. Yes leads go straight to the CRM for immediate follow up. No leads get discarded. But maybe leads — the ones who are genuinely interested but not ready right now — go into a re-engage database. Then a scheduled job runs every two weeks and sends a simple, non-pushy message: "Hey, we chatted a few weeks ago and you mentioned you might be interested later. Is now a better time?" The number of leads that convert from that follow-up is honestly surprising.
I'm not writing this to show off or act like I've figured everything out. I really haven't. But I wasted months of my life, and honestly a decent amount of my clients' money, building things that nobody used. The issue was that I was solving the wrong problem entirely. I was optimizing for technical functionality and clean code when I should have been optimizing for adoption and real-world fit. Start looking left to see what's actually feeding into your automation. Start looking right to see what really happens after it finishes. Build for the full messy real-world process, not just the clean middle step that's fun to code.
