Automating a Google Sheets workflow: what to hand the freelancer

The short answer

A Google Sheets automation is rarely hard to build. It is easy to break, because the sheet is also where people work. Someone inserts a column, renames a header or sorts the rows, and the automation quietly starts reading the wrong thing.

So the brief has to describe the sheet as a contract, not just the task. Hand the freelancer seven things: a copy of the sheet with realistic rows, a rule for each column, a status column the automation owns, the Google account it runs on, what starts each run, how many rows to expect, and who else edits the sheet. Then test it the way a busy team will actually use it. The workflow automation brief has the general fields; this guide fills them in for spreadsheets.

Why spreadsheets are different

I have built Google Sheets automations myself, and the weak spots below are the ones a brief has to cover.

In most automations, the data source is another app with fixed fields. A form always sends the same fields. A shop always sends an order in the same shape. A sheet has no such guarantee. It is a grid that anyone with edit access can reshape at any time.

That gives a spreadsheet automation three weak spots other automations do not have:

• The structure is not fixed. Columns move, headers change, tabs get renamed.
• People and the automation write to the same place. A person can overwrite what the automation wrote, and the reverse.
• The values are loose. A date can be typed as text, a number can carry a currency sign, a cell can hold a formula instead of a value.

None of these cause an error message. The automation still runs. It just reads or writes the wrong cell.

What to hand over

1. A copy of the sheet with realistic rows

Not an empty template and not your live sheet. A copy with 20 to 50 rows that look like the real thing, including the messy ones: a blank cell, a date typed by hand, a duplicate. The freelancer builds and tests against the copy, and the live sheet is connected only at the end.

2. A rule for each column

For every column the automation reads or writes, one line: what it holds, the format, whether it may be empty, and who writes it (a person or the automation). A simple table is enough:

Column	Holds	Format	May be empty?	Written by
Order ID	The shop’s order number	Text	No	Automation
Due date	When the customer expects it	YYYY-MM-DD	No	Person
Status	Where the row is in the process	new / done / error	No	Automation only
Notes	Free text	Anything	Yes	Person

Then say which columns are locked: nobody renames, moves or deletes them without telling whoever maintains the automation.

3. A status column the automation owns

This is the single most useful line in a spreadsheet brief. Each row gets a status the automation sets when it has handled that row (for example done or error). It is how the automation knows what it has already done, how you see what failed, and how a run that stops halfway can pick up where it left off.

My own content queue works this way. It is a table with one row per item and a status column the scheduled jobs read and update. On September 30, 2026, a batch run was killed halfway by low memory. Because each finished item had already been marked in the status column, the next run carried on from where it stopped without redoing anything.

The same table also showed me the other side. On the same day, a scheduling step rewrote the whole status cell of each row it touched, and the open questions I kept in those cells disappeared. I restored them from the run log. The rule I took from it: the automation updates only its own column, and only the part of it that it owns. Put that in the brief.

4. The Google account it runs on

The automation connects to Google through an account. If that is the freelancer’s account, or one employee’s personal login, the automation stops when their access changes. Ask for the connection to be made from an account you own, and make sure the sheet is shared with it. The guide on who owns the accounts covers how to set this up and take access back later.

5. What starts a run

On a schedule (“every morning at 8”), when a row is added, or when something happens elsewhere (“when a form is submitted, add a row”). Each behaves differently. A check on a timer adds some delay but is simple to reason about; an instant trigger is faster but has more edge cases. The basics page on webhooks explains the difference.

6. How many rows, and how often

Ten rows a week and ten thousand a day are different builds. Google limits how many reads and writes an automation can make in a short period, and a busy sheet can hit that limit (see rate limits). Give the freelancer today’s volume and the volume you expect in a year.

7. Who else edits the sheet

List the people who work in it and what they do: add rows, change statuses, sort, filter. If people sort the sheet, an automation that remembers “row 14” will update the wrong row. A good freelancer will design around this once they know about it.

A brief you can paste

Goal. When [event], a row in [sheet name] is [created / updated], and [result] happens within [time]. Sheet. A copy with realistic rows is attached. Column rules are in the table below. Locked columns: [list]. Status column. The automation writes only to [column], with the values new / done / error. It never overwrites other columns. Account. Connect to Google from [account I own]. The sheet is shared with it. Trigger. [Schedule / new row / external event]. Volume. About [N] rows per [day/week] now, up to [N] in a year. Other editors. [Who] adds rows and [who] changes statuses. People do / do not sort the sheet. Failure behaviour. A row that cannot be processed is marked error with a short reason, and I get one alert per run that had errors. Handover. Workflow export, a short note of which columns the automation depends on, and how to restart it.

If you are not sure the task is worth automating yet, the guide on what to automate first has three checks to run before you write any of this.

Acceptance tests specific to spreadsheets

On top of the general acceptance checklist for unattended automations, run these four on the copy before you connect the live sheet:

The re-run test matters more than it looks. My publishing pipeline keeps a ledger of everything it has published, and the job writes to it automatically on every publish, on the reasoning that a ledger a person updates by hand will eventually miss a line, and a missed line means a repeat. A status column in a sheet is the same idea.

Who to ask

Most workflow automation sellers build Sheets integrations; what differs is whether they ask about your columns before quoting. David O lists email, spreadsheet and app syncing with Make among the gig’s focus, which makes it a reasonable first message for a small, well-defined sheet job. Whoever you choose, send the column table in the first message. A seller who comes back with a question about the status column or the people who sort the sheet has understood the job.

Where it goes wrong anyway

• The sheet grows into a database. Past a certain size, a spreadsheet is the wrong place for the data, and every fix gets slower. If the seller suggests moving it, ask why and what it would cost.
• Someone renames a locked column. It will happen. Ask for a check at the start of each run that the expected headers are there, and stops with an alert if they are not.
• The process changes. A new column the automation should use is a change, not a fix. Agree how changes are priced in the maintenance terms before the first one comes up.