Google Sheets integration the spreadsheet inside the process, not instead of it
The spreadsheet is where your process touches data: people type into it, reports land in it, decisions come out of those cells. We wire it into the process so the team opens the same file while the data gets one write path, validation at the door and a trace behind every change. When the spreadsheet stops coping, the history moves to a database or a warehouse and the file stays as a view onto it.
- 300 requestshow many reads and how many writes per minute the Sheets API accepts per project, with 60 per minute per user. Limits from Google's own documentation
- 10 million cellsthe hard limit on a single Google spreadsheet. At that threshold the history goes to a database or a warehouse and the spreadsheet becomes a view
- 14 daysfrom the workshop to the first automation running on a copy of your spreadsheet, with your data in it
- 2 to 4 weekshow long a full rollout usually takes: an entry point with validation, writes through automation, a change log and the report
The problem
What happens when a spreadsheet becomes the company database?
Two people open the same file at 9:40. One types a status into row 212, the other sorts the date column in the same minute and selects only that column, without the rest of the row. After the sort, the statuses sit next to somebody else's orders. Nobody will spot it today. The client whose parcel went to the wrong address will spot it, or the bookkeeper who invoiced a different amount.
A spreadsheet has none of what a database does in the background. It does not know the VAT number column is meant to hold 10 digits. It will not refuse when the same order number lands twice. It will not lock a row somebody is already typing into. A formula returning #REF! looks like any other cell in the table, and the total underneath keeps computing, just from a different number of rows.
Then there are the limits nobody thinks about while building the first tab. The Sheets API documentation gives 300 reads and 300 writes per minute per project, with 60 per minute per user; past that the API answers with a 429 error and the automation has to know how to retry. The file itself has a hard limit of 10 million cells, this time on the Sheets side rather than the API. A process that added 200 rows a week in January walks into those thresholds in its second year and stops working without warning.
The expensive part is that afterwards you cannot reconstruct what happened. Version history will show that a row changed, but it will not answer whether the order was paid at the moment it went into production. A process with no record of who changed what, and on what basis, can neither be accounted for nor fixed.
- Nobody knows which version of the spreadsheet the rest of the company works on
- One column sorted without the rest of the row breaks the data quietly
- A formula returns an error and the report above it still looks normal
- The same number differs between the spreadsheet and the system, and nobody knows which one is true
- The file with client data is shared as anyone with the link
Why now
Why can a spreadsheet be wired into a process without taking it away from the team?
Sheets API v4 reads and writes named cell ranges from the outside: spreadsheets.values.get fetches, spreadsheets.values.update writes, batchUpdate pushes dozens of changes in a single call. The automation signs in as a service account, so it runs with nobody clicking a consent screen. To the spreadsheet it is an ordinary write. To the process it is the end of exporting to CSV.
The second piece Google added on the file side: protected ranges and data validation. You can set it so only the automation writes into the status column, only the team writes into the notes column, and the date field refuses text. The spreadsheet stops being a sheet of paper everyone writes on anywhere, and nobody has to learn a new tool to get there.
The third change is an escape route. Connected Sheets lets you put a spreadsheet on top of a warehouse, so the team builds a pivot table on data the file does not physically hold. When the data moves out to BigQuery, the tab stays the same, the numbers just arrive from the warehouse. You no longer have to choose between clean data and a tool people already know.
Then there is the AI agent. Automation will append a row, but it will not answer the question how many September lines still have no invoice number. BOND, our company AI agent, answers that in a plain sentence in 5 to 10 seconds, reading the same spreadsheet and the same warehouse.
What changes
What does a team that stays in the spreadsheet actually get?
The spreadsheet as an entry point that checks what it takes in
People keep typing, only into a place that polices the format: a VAT number with 10 digits, a date that is not in the future, a status from a list. A row that fails the check lands in a rejects tab together with a note on what is wrong with it.
Validation at the moment of typing, not during the monthly file clean up
The spreadsheet as an output the team already knows how to work in
A report from the CRM, the shop or the warehouse drops into the spreadsheet at an agreed hour, into the same tab as always, with a refresh timestamp. Nobody needs an account in the system where that data was created.
The same file and the same tabs, numbers arriving straight from the source system
One write path instead of ten people in one cell
Machine computed columns go into a protected range, so a hand typed cell stops wiping out somebody else's work. Writes go in batches through batchUpdate rather than cell by cell, which is why they do not run into the request limit.
300 writes per minute per project in the Sheets API, which is why the automation writes, not a loop over rows
You know who changed what, and at what time
Every change made by the automation lands in a log tab: timestamp, source of the change, old value, new value. Google version history stays where it is, but it stops being the only trace the process leaves.
A change log in its own tab instead of digging through the file's version history
An error in the spreadsheet reports itself
After every refresh the process checks the key columns: no #REF! in them, the row count adds up, the checksum matches the source. When something does not line up, the message goes out the same day.
A check after every refresh instead of the silence you only see in the month end report
Questions about the data in a plain sentence
How many September rows have no invoice number, which orders came in twice, who added those three rows on Friday. The AI agent reads the spreadsheet and answers, with no report to build and no file to open.
An answer in 5 to 10 seconds, from the same data the team is looking at
And in your company
What if our spreadsheet is too big to touch anything in it?
Four sentences we hear almost every time a conversation starts with a single file.
This page is about the spreadsheet as part of a process. If what you are after is order across the whole of Google Workspace, meaning Drive, mailboxes and Calendar, that is a separate service, and where to start gets decided in the workshop.
Our spreadsheet has forty tabs and five hundred formulas.
We do not touch it in the first step. We start with the question of which tabs are the process and which are somebody's private copy from last year. Usually the process sits in two or three, and nobody has breathed on the rest in a long time. The pilot runs on a copy, so the production file stands untouched until you decide to switch over.
The team will not give up the spreadsheet, they have worked in it for years.
And they are not meant to. The spreadsheet stays where it is, because talking people into a new tool costs more than the rollout itself. What changes is that data comes in through one place, machine computed columns are protected, and every change leaves a trace with a timestamp.
If a spreadsheet is a bad place for data, why keep it at all?
Because in most companies the spreadsheet is not the problem, it is the only place where the process is visible at all. Taking it away ends with the same numbers going round by email instead. We move the data to a database or a warehouse when the file approaches Google's limits, or when you need a longer history than the source system keeps.
There is client data in that spreadsheet, we are wary of outside access.
The first question in the workshop is which columns have to be there at all, because the simplest way to protect personal data is not to keep it in the spreadsheet. The automation runs on a service account with access to one file rather than the whole Drive, and you revoke that access with one click. Sharing set to anyone with the link becomes access per person or per group, and people outside the company get an expiry date.
- Google Sheets
- Google Sheets, Forms, protected ranges, data validation, version history, Connected Sheets
- Access layer
- Sheets API v4, service account, OAuth 2.0, Apps Script, webhooks
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Finance and commerce
- Xero, sevDesk, Fakturownia, Comarch Optima, BaseLinker, Shopify, WooCommerce, PrestaShop
- Data and reporting
- BigQuery, GA4, Google Ads, SQL databases
- Automation layer
- n8n, Make, Zapier, custom integrations over APIs
When the spreadsheet stays and when the data has to leave it
The signals we look at in the workshop, with the threshold and the decision that follows. The middle column is a number rather than an impression, because with spreadsheets the most expensive calls get made on impressions: either migrating too early or too late.
| Signal in the spreadsheet | The threshold where we act | What we do about it |
|---|---|---|
| The file grows every month | 10 million cells in one spreadsheet, a Google limit | the history goes to a SQL database or BigQuery, the spreadsheet stays as a view |
| Automation polls the spreadsheet in a loop | 300 requests per minute per project, 60 per user | reads and writes in batches through batchUpdate, with retries after a 429 error |
| Several people type into the same tab | 2 people in one row is enough to lose an entry | an entry point with validation, a protected range for the automation columns |
| The spreadsheet pulls data from another spreadsheet | 1 deleted column in the source breaks the target file without warning | one source of data instead of a chain of files held together by formulas |
| A formula returns an error in a key column | 1 cell with #REF! is enough to make the report untrue | a column check after every refresh and a notification the same day |
| Opening the file takes tens of seconds | 30 seconds to the first recalculation is a signal, not an inconvenience | the computing moves to SQL and the spreadsheet gets the finished result |
| Access is set to anyone with the link | 1 link is enough for the data to leave the company | access per person or per group, the file on a shared drive, an expiry date |
The thresholds come from the Google Sheets and Sheets API documentation, and Google changes them without notice. We check them in the workshop against your own file, because some of them depend on how the spreadsheet is built rather than on the row count alone.
How we work
Five steps from a spreadsheet that outgrew itself to a spreadsheet inside a process
Process first. Tools second. Every step ends with something you can judge before you decide on the next one.
Workshop
We open your spreadsheet and ask four things: where each row comes from, who changes it, what leaves it and what happens when it is wrong. We mark the tabs that are the process and the ones that are somebody's copy from last year.
Design: what is the input, what is the output
We settle on one write path, one source of truth and what stays as the view for the team. We decide whether the data stays in the spreadsheet or moves out to a database or a warehouse, and at what threshold. Permissions, protected ranges and the shape of the change log get laid out at the same time.
Pilot on a copy of your spreadsheet
The automation runs on a copy, alongside the production file that keeps working the old way. We push the last few weeks of data through it, including the rows with errors, the duplicates and the biggest month. That is usually 14 days after the workshop.
Switching over and handover
We move the process onto the production file, with the change log and error alerts from day one. The person who owns the spreadsheet learns to change what changes most often: the status list, the report recipients, the refresh hour.
Measurement at 30 and 90 days
We look at numbers, not impressions: how many rows went into rejects, how many times the process cut out, how long the work now takes that a person used to do. At 90 days we check whether the spreadsheet is still the right place for that data.
Before and after
How the week changes for the person who owns that spreadsheet
Before
- Monday goes on stitching the spreadsheet together out of exports from three systems
- She digs through version history to find who overwrote the status column
- She asks the team on chat not to sort any columns
- She hears about a wrong total from the board, a week after the fact
After
- The data is in the spreadsheet before her first coffee, with the refresh hour in the header
- Every change the automation makes has a timestamp and the old value in the log
- Machine computed columns are protected, so there is nothing left to overwrite
- She knows about an error in a key column the same day, from an alert
The first automation is visible 14 days after the workshop. The effect on the whole process gets judged at 30 days, and at 90 days we check whether the spreadsheet is still enough.
For the person signing this off
What the person who signs off those numbers gets out of it
You stop signing off a report you cannot reconstruct. You know where every column came from, who changed it and at what time, because the process records that itself. It makes no impression in a presentation, and it counts for a great deal in the week somebody asks why two numbers do not agree.
The second thing is the dependency on one person. The formulas in a spreadsheet are usually known to one human being, and their holiday stops the reporting. After the rollout the logic sits in a documented process rather than in a cell nobody looks into. When the question stops being where the data is and becomes what it means, that is already AI data analysis, the next step rather than this one.
- A trace behind every change: timestamp, source, old and new value
- A pilot on a copy, so the production file keeps working until testing ends
- Automation columns protected, a hand typed cell no longer wipes somebody's work
- A workshop at EUR 3,500 net per week, so the first step fits a budget without a board resolution
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week and runs from one to seven weeks. For a single spreadsheet in a process one week is usually enough, because the file is right there and you can see what happens in it. We quote the rollout after the workshop, once it is clear how many tabs are involved, how many systems the data comes from and whether it has to be moved out of the file.
The Sheets API is part of Google Workspace, which you already pay for, so reading and writing the spreadsheet adds no tool cost. When the process needs an orchestrator or a warehouse, you pay that bill directly to the provider, with no margin from us. A single AI agent query costs the provider roughly EUR 0.005 to 0.07, which is the order of magnitude we give you in the workshop rather than on the first invoice.
The workshop is a self-contained piece of work too. You walk out with a map of the spreadsheet, a list of columns to protect and the threshold for moving to a database, which is material your own IT person can build on without us.
Process workshop
EUR 3,500 net
per week, and for a single spreadsheet in a process that is usually one week
A self-contained piece of work. It ends with a map of the process around the spreadsheet and a plan you could carry out without us.
- A review of the spreadsheet tab by tab: what is the process, what is a copy
- A map: where the data comes in, who changes it, what comes out at the end
- A plan for the entry point with validation and the list of columns to protect
- The threshold at which data leaves the spreadsheet for a database or a warehouse
- A permissions plan, including access for people outside the company
- The measures to check at 30 and 90 days
- Most popular
Workshop and a rollout on the spreadsheet
Quoted after the workshop
scope follows from the number of tabs, systems and people in the process
The option most companies choose. The first automation 14 days after the workshop, the full rollout in 2 to 4 weeks.
- Everything in the workshop
- An entry point with validation and a rejects tab
- Batched writes through the Sheets API, protected ranges, a change log
- A report from the CRM, the shop or the warehouse landing in the spreadsheet at an agreed hour
- Checks on the key columns and an error notification the same day
- Training for the person who owns the spreadsheet
The spreadsheet and an AI agent
Quoted after the workshop
for teams that ask about this data a dozen times a day
Everything in the rollout plus BOND, which answers questions about spreadsheet and warehouse data in a plain sentence.
- Everything in the rollout on the spreadsheet
- An AI agent reading your spreadsheets and your warehouse
- An answer in 5 to 10 seconds, with no report to build first
- Gaps and duplicates in columns from a question asked in plain English
- Agent rollout takes around 2 months, counted from the point the data is ready
The workshop ends with a document that stands up without us: a map of the process around the spreadsheet, an entry point plan and the threshold for moving to a database. If it turns out that validation on two columns, one protected range and a single log tab is enough, we say so and show you how, instead of selling you a rollout you do not need.
Frequently asked questions
What is a Google Sheets integration?
It is wiring the spreadsheet into a process through the Sheets API: automation reads and writes named ranges, data comes in through one place with validation, and machine computed columns are protected from hand typed edits. The team works in the same file as before. What changes is who writes into it and how.
How does a spreadsheet work as an entry point to a process?
People enter data in a form or in a single tab with validation: VAT number format, date range, status from a list. The automation picks up the new rows, checks them again its own way and passes them on to the CRM, accounting or the shop. A row that fails the check lands in a rejects tab with a note on what is missing from it.
Can a report from our system come back into the spreadsheet?
Yes, and that is the most common scenario on the output side. Data from the CRM, the shop or the warehouse drops into the spreadsheet at an agreed hour, into the same tab as always, with a refresh timestamp. The team does not need accounts in the source system, and you do not buy BI licences for twenty people.
What happens when two people edit the same row?
The spreadsheet accepts both entries and the later one wins, with no warning. That is why machine computed columns go into a protected range and data comes in through an entry point rather than straight into a cell. Manual corrections stay where they make sense: in the notes column, which nobody quotes in an account.
Which Google Sheets limits hurt in practice?
Usually two. The Sheets API accepts 300 reads and 300 writes per minute per project, with 60 per minute per user, so automation writing cell by cell hits the threshold and gets a 429 error. The second is 10 million cells per file. The first is solved by batched writes, the second by moving the history out of the spreadsheet.
When does a spreadsheet stop being enough and you have to move to a database?
There are three thresholds: the file approaches 10 million cells, it takes tens of seconds to open and recalculate, or you need a longer history than the source system keeps. At that point the data goes to a SQL database or to BigQuery and the spreadsheet stays as a view onto it. The team opens the same file, the numbers just arrive from the warehouse.
Who can see our spreadsheet after the rollout?
The automation runs on a service account with access to one file rather than the whole Drive, and you revoke that access with one click. Sharing set to anyone with the link becomes access per person or per group, and people outside the company get an expiry date. In the workshop we also settle which columns of personal data have to be there at all.
How long does the rollout take and what do we get at the end?
A week of workshop, then 14 days to the first working automation and usually 2 to 4 weeks to the full process. At the end you get a working spreadsheet, a description of the process, a change log and error alerts. We run at most two rollouts at a time, so we agree the start date on the consultation.
Show us the spreadsheet your process runs on
The free consultation takes 30 minutes. You tell us which file matters most in your company, how many people type into it and what broke in it recently. We tell you what validation and protected columns alone can fix, what needs an entry point, and what only works once the data leaves the spreadsheet. You do not have to share the file at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If somebody in your company asked this week who overwrote that cell, this is exactly the problem. The spreadsheet stays where it is, because the team knows it. What changes is that data comes in through one place and every change leaves a trace with a timestamp and the old value. That is where the workshop starts.