From spreadsheet to script: build a voice-written automation script in one Friday

Every Friday afternoon you run a quiet ritual that nobody has written down: open the export, filter it by region, paste it into the tracker, fix the division-by-zero cells by hand, and email the summary to the team. You do it from memory, and every click is muscle memory, so the two hours vanish without a trace. The reason it never became a tool is simple, which is that nobody thinks of a personal Friday habit as software, least of all you, who has never opened a code editor. Yet this ritual is the perfect first candidate for a voice-written automation script, because it is small, repetitive, and completely describable in plain sentences that you already say to your new hires.

Watching yourself run it is the first step, and it is harder than it sounds because you are efficient. Next Friday, narrate the entire ritual out loud as you do it, exactly the way you would walk a new hire through the steps. You will be surprised by how many steps exist: the sort key, the three cells you always patch, the template you re-use, the naming convention of the export file. Those details were never missing from your head; they were only missing from any place the team could see them, and that is precisely why the ritual has stayed yours alone for months.

A repeating routine of this shape is a small, contained program. What it lacks is a language you are comfortable using, and coding by spoken description solves that without asking you to learn syntax like a programmer. You describe the sequence, and the assistant writes the script that follows it. The discipline is to describe the ritual in the order you actually do it, including the boring parts, because the boring parts are usually the ones that generate the errors. A voice-written automation script is a faithful transcript of your working week, and that is what makes it so much more useful than a generic tutorial script you found online.

Before you start, set a rough budget: one Friday, about ninety minutes, including breaks. A voice-written automation script of this scale does not need a project, a repo, or a planning ticket. It needs one recorded conversation between you and an assistant, one test run with this week's file, and one honest paragraph of instructions for whoever inherits it. If the ritual takes longer to describe than it does to run, sit with that for a minute; often the right answer is still to script the boring half and keep the judgement half manual, which is a decision you can make out loud, too.

Mapping means listing every step as an action a computer could take, and the fastest way to get that list is to dictate it while you perform the ritual once, with your microphone on. Do not try to remember the steps later in the week; memory flatters the routine and drops the two annoying exceptions. Capture the sequence in the moment, including the conditional ones: if the file has more rows than last week, then re-run the filter twice; if the region column has blanks, then treat them as the east region. The conditionals are where most hand-run rituals quietly go wrong, and they are exactly what spoken capture preserves automatically.

As you narrate, one habit will save you an hour: describe the data, not the clicks. Say: the export has a column called pipeline value and a region column, and rows after last Friday should be excluded, rather than: click the filter button here. The assistant needs to recognize the data so the script can find the columns next week, when the file is a different file. Click-based descriptions produce a script that works once; data-based descriptions produce a script that works every Friday. You already know how to describe data, because you do it when you complain about the data to a teammate.

The weird corner cases deserve their own spoken moment. Stop and say: two weeks ago the file had an extra header row, and I caught it because the totals looked wrong. That anecdote is an instruction in disguise: check the header row before summing. When you dictate anecdotes instead of writing specifications, every edge case you ever hit becomes a guard in the script, and the script slowly becomes more careful than you are on a busy Friday. This is the single biggest advantage of describing a routine to an AI rather than to a tool that only accepts formulas.

Finish the map by saying the ritual's output out loud: what is the summary you email, and what does it need to contain? Then state the failure mode: what could go wrong that would make the summary wrong rather than missing? An automation that fails loudly is easy to catch at four in the afternoon, while an automation that produces wrong numbers is a time bomb. Naming the failure mode gives the assistant something to code against, and it gives you a check to run every week. You are not building a black box; you are encoding the judgment you already use.

Now dictate the mapped steps as orders, the way you would say them to a capable intern: take the export from the downloads folder, strip the section leaders row, keep only rows from this week, and build the region totals. One sentence, one step, and a pause between steps so the assistant can ask a clarifying question. You are not writing code, and you do not need to mention any programming language at all. The assistant translates plain English orders into the script, and your job is only to keep the orders in the same order you described the ritual, which your Friday narration already did for you.

Speak in commands and in full sentences, not in fragments, because fragments lose context. Say: after the totals are built, save a copy in the shared drive with today's date in the file name, rather than: save with date. The assistant is good at guessing, but a voice-written automation script gets better when the guesses are grounded, and one full sentence costs you the same two seconds as a fragment. If you notice the assistant inferring something you did not say, correct it out loud immediately; a politely wrong guess now becomes a wrong number every Friday. The politeness is the trap: a guess that sounds reasonable gets accepted at a normal voice tempo, so slow down at the steps you have grown tired of repeating, since those are the steps you have been silently assuming.

Use the vocabularies of your own domain, not the vocabulary of programming. Sales people say account, pipeline, region, owner; an assistant that hears those words repeatedly will build the script around them, and the script's error messages will speak your language too. This matters more than it sounds, because the moment you stop understanding the script's output, you start mistrusting it, and an untrusted automation is a Friday ritual with extra steps. When the assistant asks for a clarification, answer it the same way you would answer a teammate's email question, briefly and concretely. The vocabulary contracts work in both directions: after a fortnight, the assistant will start flagging the odd cases in the same words your team uses, and the flag is then legible to whoever opens the Friday email.

At the end of dictation, ask for the plan back in one paragraph: what the script will do, step by step. Read that paragraph aloud as it appears on the screen; if any sentence makes you pause, that is the step where the assistant misunderstood you, so fix it before any code runs. This readback is the cheapest possible validation, and a spoken conversation is the natural place for it. In a typed session you would skim the plan and say yes; with voice, you are already in the mode of talking through the work, so the mismatch surfaces instead of hiding.

The moment of truth is the first run with real data, and it is best done on a copy. Point the script at this week's export and run it, then compare the output against what you produced by hand last Friday, which you still have in your sent mail. Start with the counts: rows kept, rows dropped, total per region. Numbers are the fastest lie detector, and a mismatch of two rows usually points to one of the corner cases you narrated during the mapping step. Say the mismatch out loud, walk backward through the steps the script reported, and find the step where your memory and the script disagree. That disagreement is the most valuable artifact of the whole exercise.

It is normal for the first run to fail, and the failure is a conversation, not an error. Read the message aloud and ask the assistant to explain it in one sentence of plain English, then decide whether the script misunderstood the data or the data broke its own rule. Both cases teach you something. If the script misunderstood, you re-dictate the step with more context. If the data broke its own rule, you have found a pattern that the team should know about, and the script just became an early warning system for messy exports. Either way, the second run should be boring, and boring runs are the goal.

Compare the script's summary column by column with your hand-built summary, not just the totals. The totals can agree while a subtotal is silently wrong, which is exactly the kind of failure that slips past a busy Friday. Take the extra five minutes, run both summaries side by side, and speak the differences as you scan. If a difference appears and you cannot explain why in one sentence, do not deploy the script; sit with the weirdness, because unexplained automation is how numbers start being trusted for no reason. The row-count check and the subtotal check together are the difference between helpful and dangerous.

When the run matches, run it a second time with the same file to confirm that the script is deterministic, meaning it produces identical numbers regardless of when it runs. Some automation tools quietly depend on system time or sort order, and a script that behaves differently on the second run is a script that will betray you on a random Tuesday. Say this check out loud as you do it: run twice, numbers identical, good. Once the pattern holds, save this week's output as your reference copy, and keep it for next week's comparison; the script now has a history, and history is what makes a routine trustworthy.

A script that only you can run is a personal assistant for one person, and its value jumps the moment a teammate can run it while you are on holiday. So the sharing step is real work, not an afterthought. Save the script next to the templates it uses, in the shared drive where the team already keeps the tracker, and add the three sentences of plain instructions at the top: what it does, where this week's file goes, and what to check before you trust the output. You can dictate those sentences in two minutes, and they are the entire onboarding doc this script needs.

Then pick one colleague and walk them through a single run, in person or on a call, with your voice doing the narration. Let them run it, not you, since the point is to discover the questions your instructions forgot to answer. Watch where they hesitate and turn that hesitation into one more line of instructions. The good news is that this review is language-shaped, so it matches the way you already communicate with the team; you are not demonstrating a repository, you are showing someone a Friday shortcut and telling the story of how it works. Software adoption is a story before it is a technology.

Expect a period of co-existence where some teammates still do the ritual by hand, and do not be offended, because one successful Friday for them will convert them faster than any announcement. Offer the script as a choice, not a directive. When they do use it, ask them to keep saying the output out loud at the point where it matters, which protects the team from blind trust. Over a few weeks, the script's error messages and your spoken warnings become a shared vocabulary, and the Friday ritual quietly moves from being your job to being everyone's tool. That is the end state, and it arrives faster than you think.

Finally, put the script's maintenance on the calendar, monthly, as a fifteen-minute check that a new export format or a renamed column has not silently broken it. The month check is not overhead; it is the price of freedom from the Friday afternoon, and it is far cheaper than the two hours you used to spend. Dictate a note at the end of each check about what changed, so the next maintenance session starts from knowledge instead of archaeology. That is the whole loop: capture, script, check, share, and re-check, with your own voice running the maintenance meeting, and the ritual officially becomes something the team owns without you.