From an enquiry email to a numbered pro forma, with every change approved in one click
A Make scenario reads each enquiry email with Claude, turns it into a priced, numbered pro forma PDF, logs it in the job ledger, files it and emails it to the client with a button to request a change. A second scenario is the hub for every change: Claude interprets the request, the revised pro forma goes to the owner, and one click sends it on.
Where this applies
Staffing agencies, caterers, venues and any business that quotes from free-text email enquiries and bills up front with a pro forma.
- runs, 18 Sep to 21 Oct 2026, five errors
- 143
- routes behind one revision webhook
- 5
- owner click before a revision goes out
- 1
The problem
Event and staffing work is booked by email. A client writes a paragraph (the date, the venue, how many staff, which roles, the hours) and someone has to turn it into a pro forma before anyone is booked: read it, price it, number it, make the PDF, file it, log it, send it. Done by hand, it is the job that waits until the evening, and the client who wrote first is not always the one who hears back first.
The enquiry is the easy half. Clients change their minds: two more staff, a later finish, a different date. Each change means a new version of the document, a check by the owner, a resend and an updated ledger, and with versions travelling by email it is easy to send the wrong one or to leave the ledger behind.
What we built
The model reads, a counter numbers
An Outlook mailhook passes each incoming email to Claude, which decides whether it is an enquiry at all and pulls out the details. Anything that is not an enquiry is routed to a person by email rather than guessed at. The pro forma number does not come from the model: it is read from a counter in a Make data store, and the counter is moved on, so numbers run in sequence and are never invented.
One run makes the document and the paper trail
For an enquiry, the scenario checks the job ledger in Google Sheets, generates the pro forma PDF through an HTTP call to a PDF service, adds the job to the ledger and has Claude draft the cover email. The PDF is uploaded to OneDrive, the email goes to the client, and the ledger row is updated, so the sheet always shows what was sent.
A change is a button, not a reply
The client's email carries a 'request a change' button, and the agency's website has a form for the same thing. Both post to one webhook, so a change request arrives as an event tied to a pro forma rather than as a reply in a thread someone has to find.
One hub, five routes
The revisions scenario looks the pro forma up in the ledger, then a router decides what the click was: a client's request, a form submission, the owner's approval, or another update. For a request, Claude interprets the change, the revised PDF is regenerated and filed, the ledger is updated and the owner is emailed the new version to review. Every route ends with a webhook response, so whoever clicked sees a page that says what happened.
The owner approves, then the client sees it
Approval is a click in the owner's email. The scenario downloads the revised pro forma from OneDrive, sends it to the client and records it in the ledger, so a revision never reaches a client without that click. The hub replaced two earlier scenarios that handled amendments and approvals separately; both are switched off.
The outcome
Both scenarios are live. In the run history from 18 September to 21 October 2026, the enquiry scenario ran 85 times with three errors and the revision hub 58 times with two: 143 runs and 1,043 credits between them.
Every pro forma takes its number from the same counter and is filed in OneDrive and logged in the ledger as it is sent. By design, a revised pro forma reaches the client only after the owner's click.
Where it stops
The first pro forma goes to the client as soon as it is generated: the owner's review is built into revisions, not into the first send, so a misread enquiry is caught after it has gone out. Numbering depends on a single counter in a data store. A scenario that saves the owner's answers as a knowledge base for the model is not described, and chasing payment is a separate flow.
Built with
- Make.com
- Anthropic Claude
- Microsoft Outlook
- Google Sheets
- OneDrive
- Make data store
- Webhooks
Patterns used
- AI reads, a counter numbers
- Button as the change request
- One webhook, many routes
- Approve before send
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Have something shaped like this?
If any part of the above resembles a problem you are living with, a short call is the fastest way to find out whether it is the same problem underneath.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no