How to use AI when the company still runs on a spreadsheet

If two people cannot edit the same Google Sheet without breaking a job, you do not need a keynote on agents. You need a queue: inbound email or PDF, a proposed row, a human confirm, a database that does not race. AI is the clerk who types the first draft of the row. It is not the operations manager.

Map the sheet before you touch a model

Export the tabs. Name the columns that actually matter: customer, job type, due date, amount, status, owner. Cross out columns nobody has filled in 90 days. That is your schema. If you cannot agree on a schema, a model will only speed up the mess.

The extraction loop

Inbound mail lands in a mailbox you control. A job picks up attachments. The model proposes values for those columns. A person sees the original PDF next to the proposal and hits confirm or edit. Confirmed rows go to Postgres (or equivalent). The sheet, if you still need it, is a nightly CSV. Nobody types into the sheet as the source of truth after go-live.

• Never auto-confirm amounts or dates. Those are where errors become angry customers.
• Keep the original file. When the model is wrong, you need the evidence.
• Log who confirmed. That is your audit trail when someone asks “who booked this.”

When the portal is due

You need a portal when a customer should see status, when roles matter (office versus field), or when the sheet has become the company. We build that as a scoped web app: login, jobs, statuses, export. Weekly increments. You own it. The AI clerk is optional on top — not a reason to skip the table.

What “AI ops” vendors sell that you should skip

A dashboard of “insights” with no write-back to the job. A bot that emails your customers without a template you approved. A promise to “replace ops.” If you cannot fire the feature on Friday and still run Monday, you bought a dependency, not a clerk.

How I judge whether the idea is real

I ask three questions on the first call. What job did a person do last week that you want a machine to draft? Who checks the output before a customer sees it? What happens on Friday if we turn the feature off? If you cannot answer those, we are not ready to write a statement of work. We are ready to write the FAQ or the SOP first — and that is often the actual project.

I would rather decline a fashionable chatbot than ship something that lies about hours, stock, refunds or a diagnosis. The invoice has my company’s name on it. That is why the no’s are part of the work.

What you should have in writing before you pay anyone

The job in one sentence. The data the model may see. The human who confirms. The metric you will look at in 30 days. The kill switch. The legal name of the vendor. USD price and when the card is charged. Who owns the repo. If a vendor cannot put those on one page, you are buying a demo.

• Nothing is billed by us before you approve a written scope.
• Typical project billing is 50% to start and 50% on delivery, through Stripe.
• Code, design and prompts we write for you transfer on final payment.

The steps — do these in order

1. 01

   Export the sheet and name the real columns

   Customer, job, due date, amount, status, owner. Delete zombie columns.

2. 02

   Agree who may confirm a row

   If two people can silently overwrite, you will not trust the queue either.

3. 03

   Stand up a mailbox you control

   PDFs and emails land there. Nothing goes to a consumer chatbot.

4. 04

   Propose, then confirm

   The model types the draft row. A human sees the original file and hits confirm.

5. 05

   Write confirmed rows to a database

   The sheet becomes a nightly CSV, not the company.

6. 06

   Keep the original file next to the row

   When it is wrong, you need evidence, not an argument.

7. 07

   Add a customer login only when they need status

   That is a portal. Scope it. Do not bolt ten AI widgets onto the sheet instead.

8. 08

   Fire the feature on a Friday as a test

   If Monday cannot run, you bought a boss, not a clerk. Undo it.

Keep reading

• Think. Build. Ship.

  Think. Build. Ship. — the only order that produces a product

  Think is understand the problem. Build is engineer the solution. Ship is put it into the real world. Skip one and you have a tutorial, a file, or a pitch — not a product.

• Tutorials

  Tutorials are not a product. A link is.

  You can finish a hundred tutorials and still have nothing to send. Shipping is a link that does a job — that is what SINLE Academy is for.

• Bootcamp

  SINLE Academy is not a coding bootcamp

  No job promise. No certificate as the product. Eight people, six weeks, $400 — you leave with work someone can use, not a placement story.