The headline version of this story, the one that gets shared in automation communities and turned into a LinkedIn post by someone who was not in the room, is that a small logistics firm in Chicago automated three jobs over a weekend using n8n and AI. The real version is that someone spent four months doing those three jobs badly enough that the owner finally agreed to let an automation builder touch the process. The weekend part is technically accurate. The context that makes it meaningful is not in the headline.
I know this because I was the automation builder.
The firm moved freight. Mid-size operation, regional focus, the kind of company where the operations manager is also the person who answers the phone when a driver calls at 6am with a problem. Three people were spending the majority of their time on a process that had four distinct stages: reading incoming load tender emails from brokers, extracting the relevant fields, checking those fields against a rate sheet and a capacity spreadsheet, and either accepting the tender with a confirmation email or declining it with a templated response. That was it. That was most of three people’s working days.
The owner had been told by two different consultants that this required a custom software build. One quoted him forty thousand dollars. The other quoted him sixty and used the word enterprise four times in the proposal. I sat across from him at his desk in a building that smelled of printer toner and old coffee and told him I could build something that worked for a fraction of that, that it would break occasionally, and that when it broke I would need access to fix it. He asked me if I was going to try to sell him something. I told him the only thing I was selling was the build.
The workflow I built has a Webhook node at the front that receives forwarded emails via a parsing service, which handles the messy work of turning email content into structured JSON before n8n ever sees it. That was a decision I made after spending two hours trying to use n8n’s native email trigger with IMAP and discovering that the way it handles attachments and HTML email bodies is functional but brittle in ways that would create maintenance problems I did not want to own. The documentation presents the email trigger as production-ready. For a clean plain-text inbox, it probably is. For a freight broker’s email with three forwarded headers, a rate sheet attached as a PDF, and load details buried in an HTML table inside a quoted reply, it was not.
From the webhook, the data goes into a Set node that normalises the field names, then into an HTTP Request node pointed at an OpenAI endpoint running a function-calling model. The prompt is specific: extract origin, destination, weight, equipment type, pickup date, and offered rate. Return them as JSON matching a defined schema. Do not infer. If a field is missing, return null and flag it. That instruction matters. The first version of the prompt I wrote did not include the do not infer directive and the model helpfully guessed at missing pickup dates based on context, which produced confirmations being sent for loads the firm could not actually cover on the dates the model had invented.
After extraction, an IF node checks for nulls. Any record with a null in a required field gets routed to a Slack notification that goes to the operations manager’s phone, with the raw email attached. She looks at it, decides manually, and the workflow has a second webhook that accepts her decision and routes it to the appropriate response branch. The happy path, where all fields are present, goes into a Code node that runs the rate check against a Google Sheet via the Sheets node, calculates margin, and returns a boolean. Above the margin threshold, send acceptance. Below it, send the templated decline.
The part that took the most time was not the AI integration. It was the response email templating, because the brokers the firm works with have different preferred formats and some of them will stop sending loads if your confirmation does not include specific reference numbers in specific positions in the subject line. I ended up building a lookup table in a second Google Sheet that maps broker domain to template ID, which the Code node reads before constructing the email. That is not in any n8n tutorial I have found. I worked it out by doing it wrong twice first.
The firm ran the workflow in parallel with the manual process for three weeks before switching over fully. In that time it processed 340 tenders. It made four errors, all of them caught by the null-check routing, none of them resulting in a sent email. The operations manager told me the thing she appreciated most was that when it was uncertain, it said so instead of guessing.
CrewAI, which I had considered using for the multi-stage decision logic before deciding against it, would have introduced an orchestration layer that I could not have debugged transparently when something went wrong in production. The framework is genuinely interesting. It is not ready for a workflow where an incorrect output costs someone a freight contract.
Three people did not lose their jobs. Two were moved to roles the owner had been unable to fill because he could not afford to pull anyone off the tender process. One left on her own six weeks later for a different reason entirely.
The automation did not replace people. It replaced the specific work that was preventing people from doing anything else. That distinction matters, and it tends to get edited out of the headline.
Olaitan Oladipo holds a BSc in Sociology from Olabisi Onabanjo University. He is a self-taught automation builder who has spent years inside n8n doing the work that most tutorials skip: debugging OAuth errors at 2am, migrating client automations from Make.com mid-project, fighting reverse proxy misconfigurations on AWS EC2, and figuring out through trial and error what actually holds up in production versus what only looks clean in a demo.
He is not a developer by training and not a SaaS founder. He is the person in the Discord server who actually answers the question instead of linking to the docs.
His writing on n8n Automation Tutorial covers self-hosting, AI agent workflows, tool comparisons, and the security vulnerabilities the automation industry would rather not discuss. He has built AI-assisted invoice approval flows using OpenAI function calling, connected Claude via HTTP Request nodes, and holds considered opinions about Zapier, Make.com, LangChain, and CrewAI that their marketing teams would not appreciate.
He writes for people who are technical enough to follow a tutorial but experienced enough to want the honest version.