Key takeaways
- Our blog pipeline decides which videos still need a written post by checking them against its own record of what's already done.
- On September 5 one run created and published two posts and never wrote them into that record. Both videos still looked like they hadn't been written up.
- The next day the pipeline wrote one of them again. A full duplicate.
- Our check for a duplicate web address didn't catch it, because the new post had a different address by design. The subject was the collision, not the address.
- Before drafting, we now look at the blog itself for the subject. The record is a diary, not the truth.
A lot of our content starts as a video. When a new one goes up on our channel, a pipeline picks it up, writes a blog post from it, and stages that post as a draft for approval. It's the kind of marketing automation San Jose businesses ask us about all the time: one piece of work turned into several without anyone rewriting it by hand.
The pipeline needs to know which videos it has already covered. So it keeps a record. Every time a post gets written, the video goes into a done table. Next run, it compares the channel's videos against that table, and anything not in it is fair game.
Simple, cheap, and it worked for weeks.
Two posts nobody wrote down
On September 5, one run did something different. It created two posts and published them, five seconds apart. And it wrote nothing to the done table.
We don't need to know why that run skipped its bookkeeping to see the problem. The two posts were live on the blog. The record said those two videos had never been touched.
So the next day, the pipeline did exactly what it was built to do. It compared the videos against the record, found two that looked untouched, and wrote one of them again. Same video, same subject, a full second post.
Why the safety check missed it
We did have a guard for duplicates. Before a post is created, we check whether its web address already exists on the blog. If it does, we stop.
It didn't fire, and it wasn't wrong. The second post got a different address, because every post's address is written fresh from its title and keywords. Two posts about the same video can easily end up with two different addresses. The check correctly said "that address is free."
The address was never the thing that collided. The subject was. And nothing was checking the subject.
A confident wrong answer
This is the part that bugs me most, in a useful way. When the record was wrong, the pipeline didn't throw an error. It didn't slow down or ask. It gave a clean, confident answer: this video needs a post. That answer was built on a file another process was supposed to keep current, and that process had skipped it.
An error you'd notice. A confident wrong answer, you act on.
The fix is one free call
The blog itself always knows what's been published. It can't forget, because it's the thing that got published to.
So now, before drafting, the pipeline lists the blog's recent published posts and looks for the video's subject in their titles. That's one request, it costs nothing, and it checks the real thing instead of a note about the real thing. If the subject is already there, it doesn't write it again, whatever the record says.
The done table still exists. It's useful as a diary of what each run did and when. It's just not the thing we ask anymore when the question is "does this post exist?"
The lesson we are keeping
When a decision depends on a record, ask who keeps that record current. If the answer is "some other process, usually," then the decision is only as good as that process on its worst day.
Check the thing itself when you can. Especially when checking it is free.
What this means for marketing automation in San Jose
Your business probably runs on a few records like this. A spreadsheet of which leads got called. A tag in your CRM that says a customer already got their review request. A list of who's been sent the welcome email. Each one is kept current by someone, or something, remembering to update it.
When that update gets skipped, nothing errors. A customer gets asked for a review twice. A lead gets called by two people. A new client gets the welcome email again.
Three things worth doing this week:
- Pick one automation that decides who gets a message based on a tag or a list. Find out what updates that tag, and what happens if the update gets skipped.
- Where you can, have the automation check the real event. Did the review actually come in? Did the call actually get logged? A tag someone was supposed to set is a weaker signal.
- Once a month, spot check five customers. Compare what your records say happened against what the conversation history shows.
Good marketing automation San Jose owners can trust doesn't only run. It checks the real thing before it acts, so a missed note doesn't turn into a repeat message.
Want this built for you
We build automations that check what actually happened before they act on it. Start at optechsol.llc.