creative technologist

Technology work /

Batch

An automation tool that rolled five systems into one reviewable queue.

Renamed for this portfolio — it was an internal tool.

Year
2026
Team
AV Events team
Kind
Build
What I did
Sole designer, builder, operator
Built with
Claude, then Claude Code

Scope

Workflow analysis, gate model, build, rollout, runbook.

Context

Event coordination lived in five places: two ticket queues, Slack, email and the calendar. Keeping them in sync took about four hours a day. The misses were small: a rescheduled event nobody flagged, a mistitled ticket lost in the queue, an SLA that ran out before anyone noticed.

Challenge

Create a reliable tool that makes it easier for my team’s event coordination efforts to match increasing org demand. The harder question became how much authority to give a tool that can change your calendar. I slowly gave it more, after each single step was tested and stable.

The whole system. Every write stops at the gate until I approve it.

Scheduled runwebhook · before the workdaySOURCES · READ ONLYIT Ops ticket queueWorkplace ticketsEmail (mine only)Slack (mine only)AV event calendarReconcileCompare all five againsteach other. Find what isnew, changed, missing,orphaned or off-format.Nothing is written in thisstage. It only producesa proposal.OUTPUTa list of every changeit thinks should happenSORTED INTO TWO BATCHESBatch 1 · Jiraretitle to standard formatsend SLA first responseflag SLA at riskflag quiet cancellationsBatch 2 · Calendarstandard event headersupport detail + ticket linklast-synced stampflag moved or deletedAPPROVAL GATEbatch 1, then batch 2Writes to Jiraonly the approved itemsWrites to Calendarrestructures, never deletesRun summaryevery change made, posted to Slack
  • New

    Incoming tickets in either queue that nobody had triaged yet.

  • Changed

    New comments or event changes on tickets we were already supporting.

  • Off-channel

    Slack messages carrying event updates that never made it into a ticket.

  • Uncalendared

    Tickets with no matching calendar event.

  • Untracked

    Calendar events with no ticket behind them — either queue counted, both was preferred.

  • Hand-made

    Events a human on the team created directly on the calendar, outside the process.

I did it by hand Batch proposed, I approved, Batch executed Never automated
CAPABILITYv0v1v2v3by handClaude artifactBatch, on demandBatch, scheduledRead the five systemsSpot gaps and mismatchesDraft the change batchEnrich an event I createdStandardize Jira titlesSend the SLA first responseCreate the calendar eventStart its own run unpromptedAUTHORITY BOUNDARYOverwrite what a human typedDelete anythingAssign the support engineer††† THE REGRESSION — IN EARLY TESTING, V1 DELETED EVENTS AND OVERWROTE HUMAN INPUT. EVERY VERSION SINCE IS GATED AGAINST BOTH.THE BOTTOM ROWS WERE NEVER HANDED OVER. THAT WAS THE POINT.
Each version got more authority once the last step earned it: reading, then writing, then starting its own runs. The bottom rows stayed mine in every version. When those go wrong, someone else pays for it.
What went wrongThe rule it produced
Data lossEarly in testing, Batch deleted calendar events and overwrote details we had typed in by hand. We had to rebuild the events and re-enter everything.Human-entered data became read-mostly. Batch can check it, flag mismatches, and fix formatting, but it changes content only when I approve it. And no version since has been able to delete anything, in any system.
Double-bookingTwo events landed on the same engineer in the same slot.Assignment never went into the automation. Batch surfaces the conflict and a person makes the call.
Queue rotTicket titles were all over the place, the queue was unscannable, and work got lost in it.Title standardization became part of Batch 1, applied on every sweep.
Silent changeEvents got cancelled or rescheduled and we found out late.Batch flags every cancellation, every reschedule, and any calendar event that moved or disappeared.
SLA driftResponse clocks ran out while we were busy elsewhere.Tickets near or past SLA go to the top of every run.
RepetitionI was re-explaining the same context and corrections on every sweep.I wrote a runbook Batch follows on each run. The sweeps got consistent and the system stopped depending on me.

How it works

The whole system. Every write stops at the gate until I approve it.

Scheduled runwebhook · before the workdaySOURCES · READ ONLYIT Ops ticket queueWorkplace ticketsEmail (mine only)Slack (mine only)AV event calendarReconcileCompare all five againsteach other. Find what isnew, changed, missing,orphaned or off-format.Nothing is written in thisstage. It only producesa proposal.OUTPUTa list of every changeit thinks should happenSORTED INTO TWO BATCHESBatch 1 · Jiraretitle to standard formatsend SLA first responseflag SLA at riskflag quiet cancellationsBatch 2 · Calendarstandard event headersupport detail + ticket linklast-synced stampflag moved or deletedAPPROVAL GATEbatch 1, then batch 2Writes to Jiraonly the approved itemsWrites to Calendarrestructures, never deletesRun summaryevery change made, posted to Slack
a week of manual coordination before
~20 hrs
a week of review after
~1 hr
less time spent coordinating
95%
destructive changes without my approval, once the gate was in
0

Effect

Our lean team stayed ahead of rising event demand, and coordination stopped being a second job. A company-wide tool eventually showed up with far more access than anything I could build, and it did the job better. I moved the runbook into it and retired Batch the same week.