Taking Website Publishing Off a Person

What was broken

Every week three pieces go onto my two websites. A case study on one day, a blog post on each of the other two. A person on my team did this by hand. She read the week's posting sheet, opened the admin page, and copied each piece in.

It looked like simple work. It kept going wrong. Three runs in a row failed. One title came through at 106 characters. One case study went live with its results, description, category and period all empty. Another title came through at 85 characters, all in capital letters.

None of this was her fault. Copying text into a form is work that a tired person gets wrong. And nothing checked the page before it went live.

There was a second problem. I had written myself a note that said only a signed-in browser could write to the sites. So I believed the hand step could not be removed. That note was wrong. It was right about one key being locked. But it drew too wide a conclusion from that.

What I built

First I tested the belief. Each site has its own admin login. A script can log in with the admin password, get a session, and write a post or a case study. No browser. Nobody at the machine. I checked this on both sites and it worked.

The login details stay private and never appear in any log.

Then I built a daily job. It runs at 09:30. It reads the posting sheet, finds the website items, and sends each one to the right site. Social posts in the same sheet are left alone. Those still need a real person.

Before anything is saved, a set of checks runs:

• Title length. The title plus the site name must fit in 60 characters.
• No all-caps titles.
• No empty fields.
• No client names in a case study.
• No writer notes left in the text.
• It looks at the live site first. If the item is already there, it skips it.

If any check fails, nothing goes up. The reason is written to a file, and an alert is queued for me. I added the alert on purpose. A file I never open is not an alert. A silent stop looks just like a quiet week.

I also ruled that I will not approve each post. Two things still come to me: a case study that might name a client, and anything that fails my voice check.

What changed

The daily job ran on all 8 days from 17 to 24 September. Each run left a clear line in the log, even on days with nothing to do.

In 9 days the script saved 4 items to the sites. On 4 live runs it found an item that was already published. It skipped each one and overwrote nothing. That matters, because a repeat save would have quietly reset the date on a live page.

The checks did their job too. One case study was held back on two days in a row, because a setting it needed was missing. An alert went out each day. Once the setting was fixed, the same case study went live that afternoon.

Social posts stay with the person who did this before. That is where a human is really needed.

What I would do differently

I would test my own notes sooner. One wrong line kept a person on a copy job that a script could do.

I would build the "already live" check on day one. Without it, a job that runs twice can undo its own work.

I would treat counts with care. The admin page on one site showed 21 posts. The public site showed 20, because one was unpublished. The admin number is not the live number.

And I would write down how to change the login safely, before I ever need to.