DEV Community: 2pizza.team

Does llms.txt Do Anything? The Data Says No

2pizza.team — Mon, 12 Oct 2026 13:00:09 +0000

TL;DR: llms.txt is currently placebo. Ahrefs looked at 137,000 domains and 97% of the files received zero requests. Retrieval bots were about one percent of the small remainder. Google has publicly said it will not use it. Add one in ten minutes if you want the box ticked. Do not pay a retainer for it.

llms.txt is a proposed convention: a markdown file at the root of your site that tells language models which pages matter and summarises what your site is about. The idea is reasonable and the analogy to robots.txt is obvious, which is exactly why it spread so fast through agency pitch decks.

What the measurement showed

Ahrefs studied roughly 137,000 domains that had implemented the file and looked at whether anything actually requested it. The overwhelming majority - about 97 percent - received zero requests. Among the small remainder that saw any traffic at all, the retrieval bots that would need to read the file to make it useful accounted for about one percent.

Separately, Google has said publicly that it does not use llms.txt. That matters because a convention only works if the consumers adopt it. robots.txt works because every crawler honours it. A file nobody reads is not a standard, it is a suggestion.

Why it still shows up on invoices

It is cheap to produce, it looks technical, and it is impossible for a client to disprove in the short term. A deliverable that takes ten minutes, sounds sophisticated and cannot be falsified within the engagement window is close to an ideal line item for an agency that is not being careful. We do not think most people selling it are lying - the convention is genuinely plausible and the measurement is recent.

The one honest reason to add it

Cost. It takes ten minutes and it does no harm, and there is a non-zero chance adoption improves later. Treat it the way you treat a well-formed humans.txt: hygiene, not strategy. What is not acceptable is a slide, a line item, or a monthly fee attached to it.

A related trap: make sure yours does not 404 or 500

We have found live sites where the llms.txt route threw a server error because of a framework routing default. That is worse than not having the file: an error page at a well-known path is a small negative signal about site health. If you add one, check that it actually returns the file, then forget about it.

How to check the thing that actually matters

Before any content decision, find out whether retrieval crawlers can reach you at all. This is five minutes and it outranks everything else on the list.

Request your own pages with the user agents used by AI retrieval, and look at the status code. A 403 here makes every other optimisation irrelevant.
Check your CDN or firewall rules directly rather than trusting the site to load in your browser: you are not being filtered, bots are.
Fetch a page with JavaScript disabled and read what comes back. A client-rendered app frequently serves an empty shell, and that shell is what gets indexed.
Check that the pages you care about are actually in your sitemap and return 200, not a redirect chain.

Cloudflare has blocked AI crawlers by default on new zones since July 2025. A large share of sites we look at are invisible for that single reason and have no idea, because the site works perfectly for humans.

About that correlation, honestly

The mentions figure is the strongest signal in the published work, and it should be read carefully. A correlation of 0.664 between third-party brand mentions and AI visibility is not proof that buying mentions produces visibility. Mentions are also a proxy for being a bigger, better-known brand, and bigger brands are more visible for many reasons at once.

What it does justify: spending on being genuinely present in the sources an engine already cites for your category, rather than on files nobody requests. That is a defensible reading of the data. Treating 0.664 as a lever you pull is not.

What to do with the budget instead

The published research points at third-party mentions as the strongest correlate of AI visibility - Ahrefs found r = 0.664 for brand mentions against 0.218 for backlinks across roughly 75,000 brands. Before that, check the boring thing: whether AI crawlers can reach your site at all. Cloudflare has blocked them by default on new zones since July 2025, and that single setting outweighs every content decision underneath it.

Check whether OAI-SearchBot and the other retrieval agents are blocked at your firewall. This is the highest return per hour in the discipline.
Check what a crawler actually receives from your site. Client-rendered apps often serve an empty shell.
Fix entity contradictions - two brands under one legal entity, prices that disagree between pages.
Then spend on third-party placements, mapped from the sources an engine already cites in your category.

If an agency has put llms.txt on a proposal in front of you, ask them for the request logs. It is a fair question and the answer tells you a lot about how the rest of the engagement will go. Our own take on what does work is at /geo. Ivan / 2pizza.team

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How Agencies Can Automate Client Reporting in Two Weeks

2pizza.team — Sun, 11 Oct 2026 13:00:10 +0000

TL;DR: for a ten-client agency, reporting is 30-40 hours a month, roughly $1,500-2,000 in staff time. The build is $3,000-5,000 and $100-200/month to run, so payback lands at two to three months. The work is not the integrations, it is the per-client configuration, about an hour each and unavoidable.

For most agencies Friday afternoon means reports. Someone pulls numbers out of each ad platform, pastes them into a deck template, writes the commentary, makes it presentable, and repeats it per client. Ten clients is a full day of a capable person doing data entry, every week.

This is the client-facing version. If the reports are internal, the shape and the economics differ and the general reporting guide covers that instead.

Why agency reporting breaks specifically

Data lives across platforms with different interfaces, different export formats and different opinions about what a date range is. Each client wants different metrics foregrounded. Formatting is manual, commentary is written from scratch, and if the person who does it is off on Friday, the report does not go out.

The result is that you pay a strategist to do data entry, report quality varies with who assembled it, and the whole thing has a single point of failure with a calendar attached.

The four stages

Connectors pull from each platform on a schedule. A model writes the commentary with that client's context: what changed, what drove it, what to look at next. A formatter assembles numbers and commentary into your template. Delivery sends it from your agency address on Monday morning.

Each client has a configuration: which platforms, which metrics, their KPIs, their template, their tone. Built once, runs weekly without anyone touching it.

The stage that decides whether clients trust it

The commentary. Three rules, and they are not optional. It may only reference figures that are in the data. It must never state a cause it was not given, because a plausible invented reason is exactly the kind of thing a client repeats to their board. And any week with an anomaly past a threshold you set gets flagged for a human before it sends.

That last rule is what keeps automated reporting from becoming a liability. The week a campaign collapses is the week the report must not go out on its own with a cheerful sentence about optimisation.

What you need

Unremarkable, deliberately. None of these choices is where the project succeeds or fails.

An automation platform as the orchestration layer, Make from $9/month covers most agencies
API access to each ad platform you manage, which is the item most likely to need a week of lead time
A model API key, $20-40/month at typical reporting volume
A spreadsheet or BI tool for the report template
An email sending service, free tiers cover most agencies
A written spec per client: platforms, KPIs, what the commentary should focus on

Start the platform API access first, before anything else. Approval for ad platform API access is the one dependency that can add a week and it is entirely outside your control.

Cost against what it replaces

Reporting runs three to four hours per client per month at most agencies. Ten clients is 30-40 hours. At a blended internal cost around $50/hour that is $1,500-2,000 a month spent on assembly and formatting.

The build for ten clients is $3,000-5,000, running $100-200/month. Payback at two to three months, and after that it is recovered margin. The better argument is not the money: it is that the report goes out on time in the week your strategist is ill, and that it says the same thing regardless of who is around.

The two-week timeline, honestly

Week one: connect sources, define templates, build the pull and format flow. Week two: add commentary, configure delivery, run it live for two or three clients, iterate on what they say.

The part that actually takes the time is per-client configuration, about an hour each, and it cannot be skipped because it is where the client's definition of success gets written down. Two weeks is realistic if platform API access is already in place. If it is not, that is your critical path, not the build.

Run the old process in parallel for two weeks. Not for confidence in the tooling, but because that is when you discover the client whose numbers were being adjusted by hand every week for a reason nobody documented.

What stays human

Commentary on a strategic pivot. Answering the client's questions about the report. Deciding what to test next. Creative calls. The bad week conversation, which should be a phone call and never an automated paragraph.

One thing worth naming. Some agencies bill for reporting time. If that is you, automating it changes what you are selling before it changes your margin, and that conversation with clients is a positioning decision, not a tooling one. Most agencies that make this move reposition the hours into strategy rather than reducing the fee, but decide it deliberately rather than discovering it at renewal.

If Friday reporting is eating your team, the audit at 2pizza.team/audit takes two minutes and maps your platform mix into a scope and a number. No call required.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How to Automate Lead Follow-Up Without Sounding Automated

2pizza.team — Sat, 10 Oct 2026 13:00:18 +0000

TL;DR: do not automate sending, automate the blank page. A rep writing follow-ups by hand manages about 20 a day; reviewing and approving drafts they manage 80 with the same personalisation. Build: three to four days. The approval step is not a safety net you remove later, it is the thing that makes the output good.

The bottleneck in follow-up is not judgment, it is typing and the reluctance to start. Reps know they should follow up. They do not, because attempt three is genuinely hard to write and there is always something more urgent.

So leads that showed real intent go cold, deals stall, and revenue leaks quietly enough that nobody has to make a decision about it. Your CRM shows you the problem perfectly and changes nothing.

The pattern: draft, approve, send as the rep

A deal sits idle past a threshold you choose. The system pulls the context that matters - company, contact, last note, amount, stage, days quiet - and a model drafts a short follow-up referencing what was actually discussed. The draft goes to the rep with an approve action. They read it, edit if needed, approve. It sends from their own mailbox and the CRM logs the activity.

Ten seconds per email instead of ten minutes, and the person whose name is on it still read it before it went.

Why the approval step stays

Teams always ask why not send automatically, and the answer is not fear of a bad email. Three reasons, in order of importance.

The rep owns it. Someone who clicked send behaves differently from someone the system emailed on behalf of, and that shows up in the call that follows.
The rep catches what the CRM does not know. Half of what matters about a deal was said on a call and never written down, and the model cannot see it.
Every edit is a free signal. Watch which drafts get changed and you learn exactly what the prompt is getting wrong, without running a survey.

It is also the thing that keeps this on the right side of the line between follow-up and bulk sending, which matters legally as well as commercially.

Why drafted beats templated

Templates get ignored because they read like templates, and buyers have seen thousands. A draft written against the actual deal references the objection raised last time and proposes a next step that fits the stage. Same effort from the rep, different response rate.

What goes in the instruction, specifically

Most of the quality lives here, not in the model choice.

A hard length limit. Four sentences. Long follow-ups do not get read.
Reference exactly one specific thing from the last interaction, not a summary of the relationship.
Propose one concrete next step with a time, not a request to reconnect.
Forbid inventing anything not in the supplied context. This is the rule that prevents a confident reference to a conversation that never happened.
Forbid the standard filler: circling back, touching base, hope this finds you well.
If there is nothing new to say, output nothing. A system willing to produce no draft is far more useful than one that always produces something.

That last one is the highest-leverage line in the prompt. The fourth follow-up with no new information should not be sent at all, and a model instructed to always write will always write.

Where the threshold should sit

Seven days of no activity is the common default and it is a reasonable place to start. Worth tuning by stage: a deal that went quiet right after a proposal wants a different interval from one at first contact. What matters more than the number is that the clock runs on real activity - email, call, note - rather than on the record being touched, or reps will learn to touch records.

What you need

Nothing exotic. The build is three to four days including testing.

A CRM with API access: HubSpot, Pipedrive, Salesforce
An automation platform, Make or n8n, as the orchestration layer
A model API key
Mailbox connection via OAuth, never a stored password
Wherever your team already works, for the approval step

The limits, which are not optional

This is follow-up to people already in your pipeline, which is a different legal position from cold outreach. Three things still apply and they differ by market.

An unsubscribe that works and a suppression list that every channel respects, permanently. Build it on day one, not after the first complaint.
In the EU and UK, a documented lawful basis. Existing-customer follow-up is a different case from a lead who filled a form once.
In Australia, accurate sender identification and a functional opt-out under the Spam Act, every time.

The approval step helps here too: a human seeing each message is a meaningful difference from bulk sending, both in how it is received and in how it is characterised.

What the numbers looked like

On the B2B system in our case study, 60-80 drafts a week. Reply rate moved from around 12% on manual, inconsistent follow-up to around 28% on consistent drafted follow-up. Deals that would have stalled two or three weeks were getting responses inside five days.

Read that improvement carefully, because it is easy to over-attribute. The larger share of it is consistency, not wording: follow-ups that previously did not happen at all now happen. Any system that reliably sends the second and third touch will beat one that depends on someone remembering, whoever writes the words.

Want to see the shape of this on your CRM? The audit at 2pizza.team/audit takes two minutes and no call.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Three Sales Ops Automations, With What They Actually Cost

2pizza.team — Fri, 09 Oct 2026 13:00:10 +0000

TL;DR: $6,500 to build all three, $270/month to run, roughly 50 hours a month of manual work replaced. Payback around two months. The numbers are the easy part - the section on what went wrong in each build is the part worth reading before you commission one.

I am Ivan, I build these for a living. Rather than another piece on what AI could theoretically do for sales operations, here are three systems with real numbers, including the parts that did not go smoothly.

1. Lead enrichment and scoring, B2B SaaS

The client was taking 200+ inbound leads a month through a website form, and the sales team was spending two hours a day researching each one before deciding whether it was worth a reply. Two hours a day, to sort a list.

What we built: a form submission fires a workflow. A data provider fills in company details. A model reads the company description and whatever the person typed in the form, and assigns an ICP score from one to five with a written reason. High scores route to a rep with a notification. Low scores go to nurture. Nothing is discarded.

Numbers:

Manual research: from 2+ hours a day to about 20 minutes
Rep attention: spent on the top fifth by score rather than in arrival order
Build: 6 days, $3,500
Running: $180/month across the data provider, the model and the platform

What went wrong

The first version scored confidently on leads it knew almost nothing about, because an empty company description still produces a number. Reps lost trust in the score within a week, which is very hard to win back. We rebuilt it so the model must state its confidence separately, and anything below the threshold is marked unscored and goes to a human rather than getting a plausible-looking two. The lesson generalises: a scoring system that cannot say I do not know will be ignored.

2. Pipeline reporting, logistics

The operations manager spent three to four hours every Friday building a pipeline report in a spreadsheet for the leadership meeting. Copy, paste, recalculate conversion by hand, write the summary.

What we built: a scheduled job at seven on Friday pulls the pipeline, computes stage conversion, average deal size, performance by rep and movement against last week, and a model writes a short plain-English summary of what changed. Data and narrative land in the team channel before eight.

Numbers:

Manual reporting: three to four hours to zero
Consistency: computed the same way every week, so week-to-week comparison finally means something
Build: 3 days, $1,800
Running: $60/month

What went wrong

Two weeks in, the report went out with a large drop that was not real: an API token had expired and one source returned nothing, which the arithmetic dutifully treated as zero. Leadership spent a morning on a crisis that did not exist. Now a missing source makes the report say it could not be built, loudly, instead of publishing a confident zero. Any reporting automation without that guard is a false-alarm generator.

3. Stalled deal alerts

Reps were forgetting to follow up on deals that went quiet. Deals sat in negotiation for thirty days with no activity and revenue leaked without anyone deciding to let it go.

What we built: a daily check across every open deal. Seven days with no email, call or note and a task appears for the owner with the context attached: last interaction, deal size, days in stage. Fourteen days and the manager sees it too.

Numbers:

Deals sitting 30+ days with no activity: from about 40% of pipeline to 8%
Build: 2 days, $1,200
Running: $30/month

What went wrong, and the one I would not build again

The manager alert at fourteen days was a mistake in its first form. It read as surveillance, reps started logging token activity to reset the clock, and the data got worse rather than better. We changed it to a weekly summary to the manager of how many deals were ageing, with no names, and the behaviour stopped immediately.

If you build this, make the alert serve the rep and not the audit trail. Anything that is experienced as monitoring will be defeated by the people it monitors, and they will be creative about it.

The arithmetic across all three

$6,500 to build, $270/month to run, roughly 50 hours a month of manual work removed across the teams. At a fully loaded $60/hour that is about $3,000/month of labour, so payback lands around two months and everything after is recovered capacity.

One honest caveat on that figure. Fifty hours removed is not fifty hours of new output; nobody converts recovered time at 100%. What actually happened is that the reps made more calls and the operations manager stopped losing Friday. That is worth the money, but it is not the same as hiring 0.3 of a person.

The pattern in all three

None of these is clever. Each takes a task that is consistent, high frequency and low judgment, and moves it off a person, leaving the judgment where it was. The scoring system does not decide who to call, it decides what order to look in. The report does not analyse, it assembles. The alert does not chase, it reminds.

Every one of the three failures above came from the system acting more confident than its inputs justified. That is the failure mode to design against, and it is worth asking any vendor how they handle it before you ask what it costs.

Want the equivalent numbers for your own sales operation? The audit at 2pizza.team/audit takes two minutes, no call, and gives you a breakdown for your specific stack.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Automating Real Estate Lead Follow-Up With AI

2pizza.team — Thu, 08 Oct 2026 13:00:10 +0000

TL;DR: two to three weeks, $3,000-6,000. The win is not clever conversation, it is that a lead arriving at 9pm on Friday gets a real reply at 9pm on Friday. Read the consent section before building anything that sends SMS - it is the part that can cost more than the system.

The first agent to respond usually gets the lead. That is the one thing everybody in this industry agrees on, and it is the thing manual follow-up cannot deliver, because agents are showing properties, on calls, or asleep.

What the research actually says

You will see claims of a hundredfold improvement thrown around. The figure people are reaching for comes from the Lead Response Management study, which found the odds of qualifying a lead were roughly twenty-one times greater when contact happened within five minutes rather than thirty. That study is old and its data is from web leads of its era, so treat the exact multiplier as directional rather than a law of nature.

The direction is not in doubt, and it matches the obvious mechanism: a person who has just submitted an enquiry is still sitting in front of the listing. Twenty minutes later they are doing something else and have probably enquired elsewhere too. You do not need a precise multiplier to act on that.

Why follow-up breaks without a system

Leads arrive from the website, the portals, paid social and referrals, at unpredictable times, with wildly different urgency. Some are ready now, some are a year out. Without a system, response quality is a function of how busy the agent happened to be, and the Friday-evening leads effectively get answered on Monday. Those are gone.

Consent, before anything else

This is the section most guides skip and it is the one that carries real financial risk. None of this is legal advice and at any volume you should get some.

United States: automated texting to mobile numbers sits under the TCPA, which requires prior express consent, and statutory damages are per message. Consent must be captured and logged at the point of enquiry, not assumed because someone filled in a form.
Australia: the Spam Act requires consent plus accurate sender identification and a working opt-out in every message.
EU and UK: a documented lawful basis, and consent for marketing messages to individuals.
Everywhere: honour an opt-out immediately and permanently, across every channel including the agent's own phone.

Build the consent record and the suppression list on day one, as part of the lead capture, not as a later feature. Retrofitting consent onto a list you have already been messaging does not fix the exposure you already created.

What the system does

A lead arrives from any source. Within a couple of minutes it gets a message on whichever channel it consented to, introducing the agency and opening a conversation rather than firing a brochure. It asks three or four qualifying questions in the flow of that conversation, then classifies.

What the conversation needs to establish:

What kind of property, and which areas
Timeline, which is the field that decides everything downstream
Whether finance is arranged or a lender is involved
Whether they are already working with another agent, which saves everybody time

Two rules we hold to. It identifies itself as an assistant when asked and never implies it is the agent. And it must be able to say it does not know and hand over: a confident wrong answer about a property is worse than a slow answer.

The handover, which is where these systems usually fail

A hot lead routed to an agent with no context is a lead handled twice, and the second time the buyer has to repeat themselves. The notification has to carry the whole thing: name, what they want, timeline, finance position, and the actual transcript.

And there has to be a response commitment behind it. A system that generates hot leads faster than the team can call them manufactures disappointment at scale. Decide the maximum time to human contact before launch, and staff for it.

The nurture sequence, and the buyer everyone wastes

The twelve-month buyer is frequently the best client you will ever have, and almost nobody is still in front of them when the timeline arrives. That is the real opportunity here, more than speed.

A workable shape: an immediate reply with listings that actually match what they described, a check a few days later, something genuinely useful about their area the following week, a light check on whether the timeline moved a fortnight in, then a monthly market note for their target area. Recent activity, price movement, days on market, new listings that fit. Generated automatically, useful enough to be worth opening.

The discipline that makes this work is unglamorous: if there is nothing worth saying this month, send nothing. A sequence that keeps sending because the schedule says so is how you get unsubscribes from the exact people you were being patient with.

Stack, cost and timeline

A model handling the conversation, a messaging provider for the channel, an automation platform orchestrating, and your CRM as the record. Two to three weeks: set up messaging and the qualification flow, build nurture and routing, then test on real leads and tune. $3,000-6,000 depending on how many lead sources and how awkward the CRM is.

Expect the tuning period to be real. The first version will classify some leads wrong, and the fix is watching what agents override in the first fortnight rather than guessing at thresholds up front.

Losing leads to slow follow-up? The audit at 2pizza.team/audit takes two minutes, no call, and maps what this looks like on your lead sources.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How to Automate Weekly and Monthly Reports

2pizza.team — Wed, 07 Oct 2026 13:00:09 +0000

TL;DR: single-source report, one to two days and $800-1,200. Multi-source with a written summary, three to five days and $1,500-2,500. Running cost is the platform plan. The build is easy; the spec is the hard part, and the reason most of these fail is that nobody wrote down what the report is actually for.

Reporting is the most common thing we are asked to automate, and the most reliably worth it. The pattern is always some version of the same person spending Monday morning pulling CRM data into a sheet, reformatting it, and emailing three people. For years.

This covers internal reports: pipeline, revenue, operations, the things your own team reads. If you run an agency and the reports go to clients, that is a different shape with different economics, and we wrote it up separately in the agency reporting guide.

Why this pays back faster than almost anything else

Reports are ideal automation targets because they are completely consistent: same sources, same format, same recipients, same schedule, no judgment in the mechanical part. A well-built one runs for years untouched.

There is a second return people do not anticipate. A hand-built report is subtly different every week, because the person makes small decisions each time about date ranges and what to exclude. An automated one is computed identically every week, which is the first time the numbers become comparable across weeks. Several clients have found that more valuable than the saved hours.

Step 1: write down what the report is for

Not what is in it. What decision it supports. This takes an hour and it is the step that decides whether the project works.

Then document the mechanics: which metrics, from which tools, what period, what format, what gets highlighted. Most people discover at this point that their report is messier than they believed - two sources that disagree, a column someone adjusts by hand every week, a filter nobody can explain. That is not a delay, that is the actual finding.

Be ruthless here. Half the metrics on a typical weekly report are there because someone asked once, two years ago. Automating those means maintaining them forever. Cut them now, while cutting is free.

Step 2: connect the sources

Make and n8n connect to effectively anything with an API: CRM, payments, analytics, ad platforms, spreadsheets, databases. For each source you define the endpoint, the fields, and the shape you need them in. This is the longest part of the build, typically 60-70% of the time.

Where this part goes over budget:

Date ranges. Two tools each have an opinion about what last week means, and about timezone. Pin both explicitly or your numbers will not reconcile.
Pagination. An endpoint returns the first hundred rows and the report silently understates everything until someone checks.
Rate limits, which only appear once the data set grows past the test.
A tool with no usable API, where the honest answer is a manual export step rather than pretending.

Step 3: assemble, and write the sentence

Raw API output needs cleaning and formatting. A spreadsheet is the usual assembly layer; a document template suits narrative reports and a database suits internal dashboards.

Then the part that turns a data dump into a report: a model writes the interpretation from the numbers. Sales up 12% week on week, driven by the enterprise segment, with the mid-market flat for the third week. One rule makes this safe - the summary may only describe figures present in the data, never infer a cause it was not given. A confident invented explanation in a weekly report is worse than no explanation, because people act on it.

Step 4: delivery, and the part people forget

It runs on a schedule and lands where people already are: a channel, an inbox, a shared page, a one-line summary to a phone with the key number and a link to the detail.

The forgotten part is what happens when the report cannot be built. If a source is down, the report must say so loudly rather than quietly going out with a zero in it. A zero looks like a business result. We have seen a team spend a morning on a crisis that was an expired API token.

Three ways this goes wrong after it works

The build is the easy part. These are what we see six months later.

Nobody reads it. An automated report arriving reliably is easier to ignore than a person handing it to you. If it is not driving a decision, switch it off rather than maintain it.
It drifts out of date. The business changes, the definition of a qualified lead changes, and the report keeps computing the old one. Put a review date on it, the same as you would a document.
It fails silently. Covered above, and it is the expensive one.

What we have built

Representative, to calibrate scope:

Weekly pipeline: deals by stage, new leads, closed, movement against last week
Daily revenue digest: recurring revenue, new subscriptions, churn
Weekly operations summary: order volume, fulfilment time, support ticket count
Monthly cross-tool report pulling three or four systems into one view
Ad performance: spend and return across platforms, with the written summary

Cost and timeline

Single source to a sheet to an inbox: one to two days, $800-1,200. Multi-source with custom formatting and a written summary: three to five days, $1,500-2,500. Running cost is the automation platform, $9-29/month, plus a small model bill if there is a written summary. Payback is immediate for anyone spending more than two hours a week compiling by hand.

If you spend under an hour a week on it, do not automate it. The build will cost more than it returns and you will be maintaining something to save twenty minutes.

Tell us which report you compile by hand and we will say whether it is worth automating and what it would cost. Start with the audit at 2pizza.team/audit, two minutes, no call.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

How to Automate Content Without Publishing Slop

2pizza.team — Tue, 06 Oct 2026 13:00:12 +0000

TL;DR: automate the brief, the first draft, the formatting and the publishing. Never automate the approval. A basic pipeline is $2,000-3,500 and five to seven days. The failure mode is not bad writing, it is publishing at a volume nobody is editing.

Content automation earned its reputation honestly, because most implementations are press generate and publish. The output is recognisably machine-made, readers notice, and the brand pays for it in a currency that is slow to earn back.

The version that works divides the labour differently: automation does the repetitive parts, people keep strategy, editing and the decision to publish. Done that way you get several times the output at the same quality bar, which is a real business result rather than a volume metric.

What Google's policy actually targets

Worth being precise, because the fear here is usually aimed at the wrong thing. The rule is about scaled content abuse: producing many pages primarily to manipulate rankings rather than to help anyone. Automation is not the trigger; purpose is. The October 2025 spam update went specifically after thin machine-written pages made to carry links.

Which means an automated pipeline producing genuinely useful pieces that someone edits and stands behind is not what is being penalised. A pipeline producing forty pages a month that nobody reads before publishing is, whoever wrote them. The line is editorial responsibility, and it is a line you can actually hold.

The pipeline, and which stages are machine work

Five stages: brief, draft, edit, format, publish. Automate the first, second, fourth and fifth. The third is the product.

The brief decides everything downstream

Weak output almost always traces to a weak brief, not to the model. Anybody who has handed a vague brief to a junior writer knows this already; nothing changed except the speed of the disappointment.

What a brief has to carry:

The query and what the person searching actually wants
What the top competing pieces already cover, so you can stop repeating it
Your angle: the thing you know that they do not, which is usually the whole reason to publish
Specific facts, numbers and examples to use, supplied rather than invented
Voice constraints, and the list of things you never say
An explicit instruction: where the brief provides no fact, say so rather than filling the gap

That last line is the single highest-value sentence in the whole system. A model asked to write about something it has not been given will produce something plausible, and plausible-and-wrong is the failure that costs you a reader permanently.

Voice is calibrated, not described

Telling a model to write in a friendly professional tone produces exactly what everyone else gets from that instruction. Feeding it five to ten of your genuinely good pieces and having it extract the actual patterns - sentence length, vocabulary, constructions you avoid, what you always do - produces something recognisable.

Then keep a banned list and grow it every time something slips through. Every generation failure you catch should become a permanent rule in the prompt and a check in the validator, not a note in somebody's head. That is the difference between a pipeline that improves and one that produces the same three tics forever.

The gate that cannot be removed

A draft lands wherever the editor already works, flagged with a checklist generated from the brief: these are the five things to verify in this piece. The editor spends twenty or thirty minutes refining rather than two hours writing. Approval is one action, and it triggers publishing.

The temptation, always, is to remove this step once the drafts get good. Do not. It is the only thing separating your pipeline from the thing search engines are actively filtering, and it is the only point where a person is accountable for what goes out under your name. When someone proposes dropping it, they are proposing you publish unread.

A useful signal: track how much each draft gets edited. If edits trend to zero, the briefs are good. If edits stay heavy on a category, the brief for that category is wrong, and fixing it is cheaper than editing forever.

What we automated for a fashion client

Persij needed product descriptions for 200+ items a season plus ongoing social. The pipeline takes product attributes, generates a description, bullets and three social variants, and puts them in front of a human in batch, where the review is seconds per item rather than minutes. Approved content publishes and schedules itself. A week of copywriting became about two days of review.

Note the shape of that win. The volume was already required and already being produced; what changed is what a person spends their attention on. That is the honest version of content automation, and it is a much easier case to make internally than pretending you now need ten times the content.

What to keep human, permanently

Some categories do not belong in the pipeline at all.

Anything where being wrong has consequences: legal, medical, financial, compliance
Original opinion and anything that stakes out a position, because it has to be someone's actual position
Customer stories and case studies, which depend on facts only the client can confirm
Crisis and apology, which should never be drafted by a system
Anything making a claim about your own results

Cost and what it replaces

A basic pipeline from topic to draft to review to publish: five to seven days, $2,000-3,500. A fuller version with multi-channel formatting, search research and performance tracking runs to around $4,500. Against $3,000-6,000 a month in freelance or agency production, it pays back quickly, and the more durable gain is that output stops depending on whether one person had a good week.

Want to see the shape of this for your content? The audit at 2pizza.team/audit takes two minutes, no call. If your volume is low enough that a freelancer is the better answer, it will say so.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

AI Automation for Construction Companies: What Actually Works

2pizza.team — Mon, 05 Oct 2026 13:00:10 +0000

Most AI automation content is written for office workers with laptops and fast internet. Construction is different. Your workforce is on site. Processes that work fine in an office - email approvals, CRM updates, report submissions - break down when the person doing the work is on a scaffold or in a basement with patchy signal.

Why construction is harder to automate

Three specific constraints make construction automation different from typical office automation. First: field teams often don't have work laptops or access to company software. Second: workflows are project-specific - what worked on the last project may not apply to this one. Third: the industry has a paper-first culture that's decades deep. The tools that work have to meet the team where they are, not where you wish they were.

What genuinely works: Telegram bots for timesheet submission

Telegram works on any smartphone with basic data. Every worker already has one. A Telegram bot for timesheet submission requires no app installation, no training beyond sending a message, and no laptop. Workers send a message: 'I worked 8 hours on Site A today, formwork.' The bot logs it, attributes it to the right project and cost code, and the project manager gets a daily summary.

This sounds simple because it is. But it eliminates paper timesheets, reduces payroll errors, and gives the PM real-time visibility into labor hours per project. For a company running 5-10 concurrent projects, this is a significant operational improvement.

What the Telegram timesheet system handles:

Daily time entries from field workers via simple text messages
Automatic attribution to project and cost code
PM summary report each evening
Weekly payroll export for accounting
Exception alerts when hours are missing for expected workers

Procurement approval workflows

A site manager needs materials. The old process: call the PM, wait for callback, get verbal approval, place order, submit receipt later. The automated version: site manager sends a request via Telegram or a simple web form - item, quantity, supplier, estimated cost. The system routes it based on value. Under $500: auto-approved and logged. $500-5,000: PM gets a Telegram notification and approves with one tap. Over $5,000: goes to the director with a cost-against-budget summary generated automatically.

This removes phone-tag from procurement, creates an approval trail, and gives finance a complete purchase record without anyone compiling it manually. Build time is 1-2 weeks.

Invoice processing at scale

Construction companies receive invoices from dozens of different suppliers - all in different PDF formats, all structured differently. Manual processing is slow and error-prone. Claude Vision reads any PDF format and extracts: supplier name, invoice number, date, line items, amounts. The extracted data is matched against approved POs. Matched invoices go straight to accounting. Exceptions get flagged. For a company processing 200+ invoices per month, this cuts AP time by 60-80%.

Project progress reporting

Weekly progress reports are a compliance and communication requirement on most construction projects. They're also time-consuming to write. The automated version: the PM enters structured updates (milestone status, hours worked, issues flagged) via a simple form or Telegram. Claude reads the structured data and writes a plain-English narrative progress report in the required format. The PM reviews and approves. Writing time drops from 2 hours to 15 minutes per report.

What doesn't work yet

Be skeptical of vendors selling AI solutions for these construction problems - the technology isn't reliable enough at production scale yet.

Areas where AI is not ready for construction:

Autonomous site safety monitoring via camera (too many false positives, liability issues)
Real-time equipment tracking without physical IoT hardware installed
Fully automated subcontractor coordination without human review
AI-generated construction schedules without experienced PM validation

The ROI case for construction automation

The numbers that matter for a construction company running 5-10 projects. A project manager spends 40-60% of their time on administrative work: timesheets, procurement approvals, invoices, reports. Automate that 40-60% and one PM can handle 3x more projects. At $80-120k fully loaded cost per PM, the math is significant. A $15,000-25,000 investment in the right automation systems pays back in under a year.

Implementation approach

The mistake most construction companies make is trying to automate everything at once. A 'digital transformation' that touches timesheets, procurement, invoicing, scheduling, and reporting simultaneously usually fails because the change management load is too high. Start with one workflow. Pick the one with the clearest pain and the simplest implementation. Timesheets and procurement approval are usually the right starting points - clear ROI, low risk, fast to build.

What to automate first

If you're choosing between timesheets and procurement as a starting point: timesheets first if your biggest pain is payroll accuracy and PM visibility. Procurement first if approval delays are slowing site operations. Either one takes 1-2 weeks to build and generates immediate visible results. Once one workflow is running smoothly, the team's trust in the system makes the next automation easier to adopt.

Timeline and cost

Telegram timesheet system: $2,000-3,500, 1-2 weeks. Procurement approval workflow: $1,500-3,000, 1-2 weeks. Invoice processing pipeline: $4,000-8,000, 2-4 weeks. Full operations automation covering all three: $8,000-15,000, 6-10 weeks. Monthly running costs: $100-300 depending on invoice volume and API usage. For a company with 5+ active projects, any one of these pays for itself within 3 months.

Running a construction or subcontracting business and spending too much time on admin? Book a free audit call - we'll walk through your specific workflows and tell you what's worth automating first.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Australia's Voluntary AI Safety Standard, Plainly

2pizza.team — Sun, 04 Oct 2026 13:00:09 +0000

Not legal advice, an engineering read. Updated September 2026: the ten MANDATORY guardrails that were proposed for high-risk AI have been shelved. They were replaced with non-binding guidance rather than legislation. The voluntary standard below is still the clearest statement of what responsible looks like, but nothing in it binds you. The one Australian AI obligation that does bind, with a fixed date and civil penalties, is the automated decision-making transparency requirement commencing 10 December 2026 - covered separately in the December deadline article.

The Australian Government published a Voluntary AI Safety Standard built around ten guardrails, alongside a proposals paper on mandatory guardrails for high-risk AI. The mandatory track did not survive: the proposals were dropped and the approach moved to technology-neutral regulation under existing law, plus non-binding adoption guidance. So the ten guardrails are a design brief and nothing more. Useful as one, and worth reading that way rather than as a compliance checklist.

The ten guardrails, compressed

Stripped of policy language, they cluster into four things: know who is accountable, know what could go wrong, be able to show your work, and tell people when AI is involved.

Accountability - a named owner, an internal policy, and someone whose job it is. Not a committee.
Risk management - identify and mitigate the specific harms of the specific system, documented, and revisited rather than done once.
Data governance - know what data trains and feeds the system, its quality, its provenance, and its legal basis.
Testing and monitoring - evaluate before deployment against defined criteria, then keep monitoring, because models drift and inputs change.
Human control - a person can intervene, override, or stop the system. This has to be real, not a button nobody has authority to press.
Informing end users - people are told when AI is materially involved in something that affects them.
Contestability - a person affected by an AI-influenced outcome has a route to challenge it, and that route reaches a human.
Supply chain transparency - you know what is in the AI you bought, and you can tell your own customers.
Record keeping - documentation sufficient for someone else to assess compliance later.
Stakeholder engagement - consider the people affected, particularly on safety, diversity and fairness.

Which ones cost real engineering effort

Most of the list is organisational and costs meeting time. Four of them are genuine engineering work, and they are the four that are painful to add late.

Testing and monitoring - needs an evaluation set, a defined pass criterion, and drift monitoring on inputs and outputs. If you have never built this, it is a real project, not a checkbox.
Human control - an override path has to exist in the data model, not just in the interface. A system that cannot record 'a human overrode this, and why' cannot demonstrate human control.
Contestability - requires that you can reconstruct why a specific decision came out the way it did, for a specific person, months later. That is a logging and explainability requirement.
Record keeping - the documentation only exists if it is generated as you go. Nobody successfully writes it retrospectively.

The model choice this pushes you towards

Contestability and human control are much cheaper to satisfy with a model that can explain a specific decision. Gradient boosting on your own tabular data returns per-feature attribution for every prediction, so 'why was I declined' has a real answer. A language model asked to produce the same score gives you a plausible sentence that may not describe the actual computation, which is worse than no explanation because it looks like one.

This is the same conclusion we reach for reasons that have nothing to do with regulation - determinism, cost at volume, auditability. It is convenient when the compliant choice and the engineering choice are the same choice, and it is worth noticing when they are not.

What happened to the mandatory track

It was abandoned. Australia proposed ten mandatory guardrails for high-risk AI and, roughly fifteen months later, shelved all of them in favour of regulating through laws that already exist - the Privacy Act and Consumer Law - with non-binding guidance on top. If you built a compliance plan around those ten becoming law, that plan is now aimed at nothing. The engineering underneath it is still worth doing, for the reasons in the sections above, but call it engineering rather than compliance.

The practical question for an SMB is therefore not 'do we use AI' but 'does our AI make or materially influence a consequential decision about a person'. If yes, design against the guardrails now. If no, take the four engineering ones anyway because they are just good practice, and skip the governance overhead.

A proportionate response for a small business

The failure mode here is a small company building an AI governance programme it does not need, and the opposite failure mode is a small company automating a hiring decision with no logging at all. Both are avoidable.

Write down what each AI system does, who owns it, and what happens if it is wrong. One page per system is enough to start.
Decide explicitly whether any of them influence a consequential decision about a person. That answer sets the effort level for everything else.
For anything that does: log the inputs, the output, and any human override, and make sure you could explain one specific decision a year from now.
Tell users when AI is materially involved. This is cheap, it is increasingly expected, and it is the thing customers notice you hiding.
Do not write a policy you will not follow. An unfollowed policy is worse evidence than no policy.

This area moves, and a blog post is the wrong source for a date: verify current status before any compliance decision. What is not in doubt is the automated decision-making transparency obligation commencing 10 December 2026, which does carry civil penalties. If you run an automation that touches personal data and makes decisions about people, that one has your name on it. The audit at /audit is free. Ivan / 2pizza.team

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

CRM Automation That Does Not Break at Scale

2pizza.team — Sat, 03 Oct 2026 13:00:11 +0000

TL;DR: Zapier is genuinely good for simple connections and genuinely wrong for business logic your revenue depends on. The dividing line is not volume, it is what happens when step four of seven fails at 2am. Build routing on Make or n8n, put a real enrichment layer in front of it, and design the failure path before the happy path.

Most CRM automation stories go the same way. Someone builds it in Zapier over a weekend and it works. Volume doubles. Something breaks quietly. A day disappears into working out why four hundred leads got the wrong email, and nobody can reconstruct the order things ran in.

This is not an anti-Zapier piece. I use it. The failure is not the tool, it is putting business logic somewhere that was designed for connections.

The real dividing line

It is not lead volume and it is not step count. It is this question: when a step fails halfway through, does anything notice, and can you tell what already happened before it stopped?

If the answer is that a person notices eventually, you are fine on a simple connector and should not overbuild. If the answer needs to be that the system notices, retries the recoverable part, and does not redo the part that already succeeded, you are past what a connector is for, whichever brand is on it.

Being fair about Zapier

It has error notifications and it can replay failed runs, so the flat claim that it has no error handling is wrong and you will find it repeated all over the internet. What it does not give you is the thing that matters at scale: branching failure paths, retry with backoff on the one flaky API, and idempotency so a replay does not send the same person a second email. You end up assembling those out of code steps, and at that point you are maintaining code inside a no-code tool, which is the worst of both.

And about cost

Zapier bills per task, meaning per action step that runs, so a seven-step Zap firing a thousand times a month is around 7,000 tasks. As of September 2026 the ladder is Free at 100 tasks, Professional from $19.99/month, Team from $69/month, with the price rising along a usage slider. The old Starter tier that half the comparison articles still quote does not exist. Make starts at $9/month for 10,000 credits. The gap is real but it is the second reason to move, not the first.

What a stack you can trust looks like

Which of those two fits you is its own question, worked through in our three-way comparison. For work the business depends on we build on Make or n8n with a model doing the judgment calls. Here is a lead qualification and routing system, concretely.

The path a lead takes:

A webhook fires when a lead lands in the CRM, and the lead ID is recorded before anything else happens
Enrichment fills in what the form did not capture: industry, company size, intent signals from what they typed
Routing assigns to the right person by territory, segment or account size, using the enriched fields rather than the raw ones
A first-touch reply is generated against your criteria and sent within minutes
No response in five days and a follow-up task appears on the owner's list
The CRM record is updated with the enrichment, the routing decision, and what was sent

The first bullet is the one people skip and the one that matters. Recording the lead ID before any work happens is what makes a retry safe: on a second delivery the system sees the ID, knows what already completed, and does not send a duplicate. Webhooks are delivered at least once, not exactly once, and any system that assumes otherwise will eventually double-email someone you wanted to impress.

When a step fails, it retries with backoff. Errors are logged with enough context to reconstruct the run, and a notification goes to a channel someone actually reads. One of these has been running for a client for eight months without intervention. The uptime is not the interesting part; the interesting part is that nobody has had to ask what happened.

The enrichment layer, which is where routing actually lives or dies

Raw CRM data is incomplete in a specific way: you get a job title and no company size, a company name and no industry. Routing rules written against fields that are empty half the time do not fail loudly, they just route badly, and that looks like a sales problem rather than a data problem for about a quarter.

So enrichment runs before routing, not after: contact and company data from a provider, and a model classifying intent from whatever the person actually wrote in the form. The output is a record with industry, a size estimate, and an intent score. Now routing is reliable, because it is reading fields that are populated.

Two rules we hold to. Enrichment must be allowed to say it does not know, and a record it could not enrich goes to a human rather than down a default branch, because a confident wrong classification is worse than an empty field. And whatever you enrich with has data-protection consequences in the EU and under the Australian Privacy Principles, so decide that deliberately rather than discovering it later.

Reporting, without the Monday ritual

The other thing that breaks in every CRM setup: someone pulls the numbers each Monday, pastes them into a sheet, rebuilds the same chart. Then does it again.

Replace it with a scheduled job. At eight on Monday, pull the pipeline from the CRM API, compute stage conversion, average deal size and movement against last week, have a model write a short summary of what changed, and put it in the channel before anyone sits down. The value is not the saved hour. It is that the number is computed the same way every week, so a change in it means something changed in the business rather than in who built the sheet.

When not to build any of this

If your lead volume is genuinely low and one person reads every enquiry, a connector doing two steps is the correct answer and this article is over-engineering for you. The cost of building a resilient pipeline is only worth paying when the cost of a silent failure is real: a lead lost, a customer emailed twice, a number in a board deck that was wrong for three weeks.

The signal that you have crossed over is usually not volume. It is the first time somebody asks whether the report is right and nobody can answer quickly.

Want to know whether your setup is past that line? The audit at 2pizza.team/audit takes two minutes, no call, and if the honest answer is that your current Zaps are fine, it will say so.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Make Pricing Explained: What You Actually Pay

2pizza.team — Fri, 02 Oct 2026 13:00:12 +0000

TL;DR: Make charges per module execution, not per workflow run. A scenario with 10 modules running 500 times costs roughly 5,000 credits, not 500. Free $0 for 1,000 credits, Core $9, Pro $16, Teams $29, each for 10,000 credits a month. Most small businesses land at $9-16. If you are over 150,000 credits a month, look at n8n.

One terminology note before anything else, because it will confuse you against older guides: Make used to call these operations and now calls them credits. Same unit, new word. Every tutorial written before 2026 says operations and still applies.

What counts as a credit

Every time a module inside a scenario executes, that is one credit. This is the single fact that determines your bill, and it is the one most people get wrong on their first estimate.

Counts:

Every action module: create a row, send an email, call an API
Routers, each path that actually runs
Filters that evaluate and pass
Aggregators and iterators, per item processed
Error handler modules when they fire

Does not count:

The trigger, the first module that starts the scenario
Paths that a filter blocks before any module runs
A scenario that errors before any module executes

The iterator line is the one that bites. A scenario that fetches an order and then loops over its line items does not cost one credit per order. It costs roughly one per line item, per module inside the loop. A store averaging six items an order can be six times more expensive than the first estimate suggested. Check every loop in your design before you trust a number.

The plans, verified September 2026

Taken from make.com/pricing directly. All the paid tiers quote the same 10,000 credit bucket, and the price rises along a slider as you need more, up past 8 million a month.

Free: $0, 1,000 credits/month, limited active scenarios, 15-minute minimum interval between runs
Core: $9/month for 10,000 credits, unlimited active scenarios, scheduling down to the minute, Make API access
Pro: $16/month for 10,000 credits, priority execution, custom variables, full-text execution log search
Teams: $29/month for 10,000 credits, team roles, shared scenario templates
Enterprise: custom pricing, overage protection, advanced security

The Free plan's fifteen-minute minimum interval matters more than the credit limit for most people. If you need something to happen when an order arrives rather than within a quarter of an hour, Free is not a trial of your use case, and the $9 tier is the real entry point.

Worth knowing what the $7 step from Core to Pro actually buys: full-text search across execution logs. That sounds minor until the first time something goes wrong in a scenario that has run four thousand times and you need to find the one run that failed. We put clients on Pro for that reason alone.

Typical usage, by how much you automate

Rough bands from what we see in small businesses. Use them as a sanity check on your own estimate, not as a substitute for making one.

Light: three to five simple scenarios, low volume, 2,000-5,000 credits/month. Free or Core.
Moderate: around ten scenarios on daily triggers, 15,000-40,000 credits/month. Core or Pro plus a larger bucket.
Heavy: twenty or more scenarios on real-time triggers, 100,000+ credits/month. Pro or Teams at a high slider setting, and worth pricing n8n against it.

Estimating your bill before you build

Five minutes with a pen saves a surprise in month two. The method:

Count the billable modules in the planned scenario, excluding the trigger
Multiply by expected runs per month
For any loop, multiply that section by the average number of items
Add 20% for error routes, retries and the paths you have not thought of
Price that number on the slider, then check it against the volume you expect in a year rather than today

Worked example: an eight-module email automation with no loops, running 1,000 times a month. That is 8,000 credits, plus 20% is 9,600, which fits inside Core at $9/month with a little room. Now the same scenario with a three-item average loop over four of those modules: roughly 4,000 plus 12,000, so 16,000 before buffer. Same scenario, double the bucket. That is the difference the loop makes.

Where it gets expensive, and what to do about it

Make becomes cost-inefficient on high-volume real-time events: every order, every form submission, every inbound email. A store doing 500 orders a day through a twelve-module scenario is around 6,000 credits a day, 180,000 a month. At that point you are well up the slider and it is worth comparing against a self-hosted n8n instance, where the cost is server hosting in the tens of dollars rather than a usage bill.

The honest counterweight: self-hosting means you now own uptime, updates and backups. If nobody on your team wants that job, the usage bill is buying you something real. The switch makes sense when the saving is large enough to pay for the attention it costs, which in practice is somewhere north of $100-150/month in Make spend.

Cutting credits without changing what the system does

Before you migrate, most scenarios have easy waste in them. These are the four we find most often.

Filter early. A filter that blocks a path before the modules run costs nothing; the same filter at the end has already paid for everything upstream.
Stop polling. A scenario checking for new rows every minute burns credits all day finding nothing. Use a webhook where the source supports one.
Batch instead of looping. Many APIs accept multiple records in one call, turning fifty module executions into one.
Delete the dead ones. Every account we audit has scenarios still running for a process that ended last year.

Against Zapier, on cost

The wider head-to-head, including where each one wins, is in our three-way comparison. Zapier charges per task, meaning per action step that runs, and starts at Free with 100 tasks, then Professional from $19.99/month. Make starts at $9 for 10,000 credits. The units are not equivalent, so normalise before you conclude anything: count billable steps, multiply by runs, price both sliders. Even after normalising, Make comes out materially cheaper for equivalent volume in every workload we have measured, which is why businesses that outgrow Zapier generally move rather than climb its tiers.

Want your credit usage estimated before you build anything? That is a ten-minute job and we will do it. Start with the audit at 2pizza.team/audit, no call required.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.

Automating Shopify Order Processing: The Full Workflow

2pizza.team — Thu, 01 Oct 2026 13:00:10 +0000

TL;DR: three to five days, $1,500-2,500, $9-16/month to run. Worth it from roughly 20 orders a day. The whole difficulty is in four places: duplicate webhook delivery, partial fulfilment, failed payments, and returns. Everything else is wiring modules together.

Shopify gives you the store. It does not do the work behind it. Every order still needs someone to check stock, tell the warehouse, produce a packing slip, get a tracking number in, and tell the customer. At five orders a day you cope. At fifty you do not.

This is the deep version, covering order processing only. If you want the wider picture across orders, support and reordering, the full store guide covers that at a higher level and this goes underneath it.

The happy path, which is the easy 20%

Shopify fires a webhook on a new order. Your scenario catches it and runs: check stock, notify whoever packs with the order and instructions, generate the packing slip, create the shipment with the courier and pull the tracking number, send the customer a real tracking email. Order to warehouse notification in under two minutes.

Building that takes a day. Building the version that is still correct in month six takes the rest of the week, and the difference is entirely in the four problems below.

Problem 1: webhooks arrive more than once

This is the one that costs real money and almost nobody builds for it. Shopify guarantees at-least-once delivery, not exactly-once. If your endpoint is slow or returns an error after doing half the work, the same order is delivered again.

Without a guard, that is a second pick instruction to the warehouse, a second confirmation email to the customer, and sometimes a second shipping label you paid for. It does not look like a bug, it looks like a strange busy day.

The fix is small and must come first in the scenario: record the Shopify order ID before doing anything else, and on every delivery check whether that ID has already been handled. If it has, stop. This makes retries safe, which in turn makes it safe to retry deliberately when a downstream API is flaky.

Related and just as important: answer the webhook fast and do the work afterwards. A scenario that spends forty seconds calling a courier before responding will be re-delivered by Shopify while it is still working. Acknowledge, then process.

Problem 2: orders do not ship all at once

An order with three items where one is out of stock is not an edge case, it is Tuesday. If your automation treats an order as a single unit, it will either hold the whole thing until everything is available, or mark the order fulfilled when the first part ships.

Both are bad for different people. The first annoys a customer who would happily take two items now. The second tells them their order shipped when half of it did not, which produces a support ticket and a refund request.

Decide the policy explicitly before building: ship what is available and track the remainder as a separate fulfilment, or hold, with a rule for how long. Then build it. The default of not having a policy is what generates the tickets.

Problem 3: paid is not the same as captured

A webhook on order creation fires for orders whose payment later fails or is flagged for review. If your warehouse notification goes out on order creation, you will occasionally pick and ship goods for an order that never pays.

Trigger the fulfilment path on payment status rather than on order creation, and treat a pending or under-review payment as a hold rather than a go. The correct trigger is boring and it is the difference between a system you can leave alone and one somebody has to watch.

The same logic applies in reverse: a cancellation or refund after your scenario ran needs to reach the warehouse. If the only path is order creation, nobody downstream ever hears that an order was cancelled.

Problem 4: returns, where most automation stops

Returns are less predictable, so they get left manual entirely. That is an over-correction: roughly 70% of return requests follow a shape. The customer submits a request, the system checks that the order exists and is inside the window, approves, sends the label, updates the status.

The other 30% fall outside the rules and go to a person. Automating the 70% is a large saving and carries little risk, as long as the boundary is a rule and not the model's judgment. Anything touching a refund amount, a goodwill decision, or a customer who is already unhappy goes to a human by default.

The inventory loop, which is harder than orders

Order processing is a straight line. Inventory is a loop, and it is where most stores are still doing it by hand: checking stock and emailing suppliers when something looks low.

The automated version: a processed order decrements the SKU, and when a SKU crosses its reorder point a second flow drafts and sends the supplier order. We have run this for Simbago for over a year with no stockouts.

Two things make it work rather than misfire. Set the reorder point from sales velocity and supplier lead time rather than a flat number, because a SKU selling twenty a week needs a different trigger from one selling two. And for the first fortnight, send the draft to yourself rather than the supplier. An automation ordering the wrong quantity from a real supplier is an expensive way to discover your thresholds were guesses.

What you need

The stack is unremarkable and that is the point.

An automation platform: Make from $9/month covers most stores, n8n if you want self-hosting
A Shopify webhook on order events, configured in the admin under notifications - Shopify moves this occasionally, so search the admin rather than trusting a path from any article including this one
A channel the warehouse actually reads, which is usually not email
A sheet or database for inventory, if it is not already in Shopify
A courier API, if you want labels generated rather than typed
An email sending service for customer notifications

Cost, and when not to bother

Three to five days to build and test, $1,500-2,500 as a project, $9-16/month for the platform. It pays back within a month for a store doing 20+ orders a day.

Below about ten orders a day, do not. You will spend more on the build than the time is worth, and a person handling ten orders catches the odd ones automatically. Automate this when the volume has made that impossible, not in anticipation of volume you do not have yet.

Running a store and unsure which parts are worth automating first? The audit at 2pizza.team/audit takes two minutes, no call, and gives you an order of operations rather than a pitch.

Originally published at 2pizza.team. We build AI and automation systems for small teams - fixed price, two to six weeks. See the work.