A furniture company came to me with a problem that sounds simple.

They needed to send customers updates when their custom orders moved through production. In production. Complete. Ready for delivery.

They were doing it manually. Someone would check Shopify, see an order was ready, copy the customer's email, write the update, send it.

For hundreds of orders a month. Every single one manually.

They wanted it automated.

What We Built

The system monitors their Shopify orders every five minutes. When the team updates an order's status in Shopify, the automation sends the appropriate email to the customer automatically.

No buttons to click. No extra steps. Just update the order like you normally would and the customer gets notified.

Nine different email templates depending on what's happening:

Every email logs automatically to the order notes with a timestamp. Complete audit trail of what was sent when.

Sounds straightforward. It mostly was. Except for the part I got wrong.

The Thing I Messed Up

Here's what I didn't think through carefully enough at first.

The "order is in the queue" email was supposed to send 24 hours after an order was placed. That buffer gives them time to check inventory and make adjustments before telling the customer anything.

Once that email sent, the system tracked it by setting a field called "last email sent" to "Queued."

Then when the order went into production, they'd update the status and a different email would send.

Simple logic: if the current status doesn't match what was last sent, send the new email.

Except that logic created a problem I didn't anticipate.

The queue email trigger was based on a field called "fulfillment type" being set to "Made to Order." Once that queue email sent, I told the team they needed to clear that field so the status emails would work properly.

That's an extra manual step. The whole point was to eliminate manual steps.

Worse, if they forgot to clear it, the status emails wouldn't send at all. The system would see "Made to Order" was still set and get confused about what email to send next.

I'd built something that required the team to remember an arbitrary technical rule that existed only because of how I'd structured the logic.

That's bad automation.

How I Fixed It

Three weeks after launch, I rebuilt the core logic.

Now the queue check and the status check are completely independent. They don't interfere with each other at all.

Queue email: only sends if NO email has been sent yet and the order is 24+ hours old.

Status emails: send whenever the status changes, regardless of what the "fulfillment type" field says.

The team can leave "Made to Order" set permanently. It doesn't matter. The status emails work anyway.

No more manual clearing of fields. No more remembering technical rules. Just update the order status and everything happens automatically.

That's how it should have worked from the beginning.

What Actually Took Time

The technical part was straightforward. Pull order data from Shopify. Check if status changed. Route to correct email template. Send email. Update tracking.

That's maybe three days of work including testing.

The part that took time was everything around that.

Understanding their actual workflow. They have three different delivery partners. Each partner needs slightly different messaging in the email. Orders go through different production timelines depending on whether it's lighting, furniture, or rugs.

None of that was documented anywhere. I had to sit with the team and map out every scenario. "What happens if this?" "What do you tell customers when that happens?"

Then building the email templates. Not the technical part of building them. The actual messaging. What tone do they want? What information do customers need at each stage? What questions does this email need to answer?

I went through probably six drafts of each email with their team before we landed on versions that felt right.

Then there's the edge cases. What if someone changes the delivery partner after the first delivery email already sent? What if they need to move an order backwards in status? What if an order sits in queue for more than 24 hours but the status never gets updated?

All of that requires thinking through the logic and making decisions about how the system should behave.

The code is the easy part. Figuring out what the code should actually do is where the work is.

Why This Actually Matters

The system saves them probably 15 hours a week. That's 60 hours a month they're not spending on manual email management.

But the bigger impact is consistency.

Before, customer communication depended on who was working that day and whether they remembered to send the update. Some customers got detailed information. Some got one-sentence emails. Some got nothing and had to reach out asking for updates.

Now every customer gets the same clear communication at the exact right time. Every single order. Without anyone having to remember to do it.

That's what good automation does. It removes the manual work and makes the process reliable.

What I'd Do Differently

If I built this again from scratch, I'd spend more time upfront mapping the workflow before writing any code.

I jumped into building too fast. Built the queue email logic before fully thinking through how it would interact with the status emails.

That's why I had to rebuild it three weeks later.

I should have drawn out the entire flow on paper first. "If this field is set and that field is set, what happens?" Work through every combination before writing a line of code.

Would have saved me the rebuild work.

The other thing: I should have tested more edge cases before launch. The system worked fine for the happy path. Order goes from new to queued to in production to complete to delivery. Perfect.

But what about the unhappy paths? What if someone makes a mistake and needs to change things? What if an order skips a step? What if they need to send a delivery email twice because the first delivery attempt failed?

I found those issues during the first few weeks of production. Would have been better to find them during testing.

The Documentation Problem

The other time-consuming part was documentation.

I built a 34-page manual for this system. User guide, technical documentation, troubleshooting guide, maintenance plan.

That took almost as long as building the system itself.

But it's necessary. The team needs to know how to use it. They need to know what to do when something breaks. They need to know how the system actually works so they're not just blindly trusting a black box.

I see consultants skip this part all the time. They build something, show the client how it works once, then disappear.

Six months later the client has questions. Or something breaks. Or they want to modify it. And they have no idea how anything works because there's no documentation.

That's not doing the job completely.

What This Project Taught Me

You can't just automate a process. You have to understand the process first.

I thought I understood their workflow from our initial conversations. I didn't. Not really. I understood the basics but not all the nuances.

That's why the first version had issues. I built what I thought they needed instead of what they actually needed.

The rebuild worked better because by then I'd seen the system run in production for three weeks. I'd seen the edge cases. I'd talked to the team about what was annoying them.

That's when I actually understood the workflow well enough to build the right solution.

The lesson: spend more time in discovery. Ask more questions. Map out more scenarios. Don't start building until you actually understand the problem.

The technical skills matter. But understanding the problem matters more.