My standards, written out and version-stamped like a contract, with a signature at the bottom. Nobody works an event for me until they've acknowledged it. That rule has no exceptions, and it started with a bad tax season.
The thing that finally made me build this was tax season. I sat down with a stack of contractor payments from a busy year and discovered that some of the people I'd paid had never given me a W-9. Not because anyone was hiding anything — because they'd been booked in a hurry, they shot well, I paid them, and the paperwork was a thing I intended to sort out later. Later arrived in the form of my accountant asking a question I didn't have an answer to.
The second problem was quieter and cost me more. My standards lived in my mouth. I explained them on the phone, or in a text the night before, or in the car on the way to a venue. Which means every person on my team had heard a slightly different version, delivered at a slightly different level of detail, depending on how rushed I was that week. Then something would go sideways — files delivered in a state I didn't expect, a card formatted before I'd confirmed the backup, someone posting an image from a wedding before the couple had seen it — and I'd have the same realisation every time. I never actually told them. I told someone. I couldn't have told you who.
Verbal standards do not survive a busy season. They survive one conversation, and then they degrade with every retelling, and you never notice the degradation until it produces a problem you have to apologise to a client for.
Three things, and they're all boring, which is why they work.
Put the standards somewhere they cannot be lost — not a text thread, not a PDF attached to an email from March, not your memory. Make agreement explicit rather than assumed, because "I sent it to them" is not the same as "they read it" and only one of those is worth anything when there's a disagreement. And version it like a contract, so that a year from now you can say precisely which document a specific person agreed to on a specific day.
What I ended up with is one page at alexknightstudio.com/onboarding — go and read the real thing, it's the same page my team signs. It's kept out of my sitemap and carries a noindex tag, because it's for my team rather than for search engines. I send the link to anyone I'm bringing on, and they read it and sign it before they're on a schedule for anything.
The standards are written out in numbered sections. Numbering matters more than it sounds — it means I can say "section four" in a text message and we both know exactly what we're talking about. Here's what each section is there to settle, before it becomes an argument at eleven at night after a long day.
What comes back to me, in what format, and in what state. "Send me the files" means five different things to five different photographers, and the gap between what I assumed and what arrived used to cost me an evening of sorting.
When a card may be formatted, and how long a shooter holds their own copy before clearing it. This is the section that exists because of what happens on the one day a drive fails, and it's the one I'd write first if I were starting over.
What gets recorded, by whom, and how it comes back. Small section, entirely unambiguous, saves a specific and very painful category of "I thought you had it."
What my team wears. It reads as fussy written down and it isn't — at the level I work, how the crew looks is part of what the client is paying for, and nobody can meet a standard they were never given.
How and when to bill me, in a specific format, so that paying people is a five-minute task rather than an archaeology project.
What can be posted, when, and with what credit. This is the one people most often get wrong in good faith — posting a favourite frame the next morning feels harmless right up until the couple hasn't seen their own photographs yet.
How we behave with clients, with their families and guests, and with other vendors. The bar is: you are representing my studio, and everyone in that room should come away thinking well of it.
Who to call, and about what. On a wedding day nobody should be guessing whose number to find.
Then, at the bottom, the part that turns a document into a record: an acknowledgment form. Full legal name, email, phone, what type of work they're here for — photography, video, assistant, or other — their gear brand, their hourly rate, and whether they have a car. Plus a required checkbox confirming they've read the whole thing.
Two of those fields do more work than you'd expect. Gear brand matters because matching systems across a team makes a difference to how the day runs. And whether they have a car is the single most practical thing on the form — a venue two hours outside the city changes who I can realistically send, and I'd rather know that from a database field than from a phone call at seven in the morning.
When someone signs, the submission lands in my site's form handling, I get an email notification, and a small piece of server code automatically sends the signer a branded copy of their own acknowledgment — their name, their role, the date, and the version they agreed to. That last part is deliberate. The record now exists in two inboxes, one of which isn't mine. Nobody has to take my word for what they signed, because they're holding a copy of it. Everyone who signs also flows into the team roster on my private admin dashboard, grouped by what they do, which is how I actually staff a weekend.
At the top of the page there's a version and a date — "v1.0 — August 12, 2026." When I change the standards, I bump the version. Every signature records which version that person agreed to.
This is the difference between a document and a vibe. Without it, "you agreed to my standards" is a claim about a page that has been edited an unknown number of times since anyone looked at it — which is to say, it's worthless the moment it's disputed. With it, I can tell you that a specific person agreed to a specific document on a specific date, and I can produce that exact document. If I've since changed something material, that's not a problem, it's just a fact: they agreed to v1.0, we're now on v1.2, and anyone still working under the old version needs to re-sign. That's a two-minute conversation instead of an argument.
It also imposes useful discipline on me. Bumping a version is a small ceremony, and small ceremonies make you think before you change something. I've talked myself out of pointless tinkering more than once because I didn't want to push a new version over it.
Here's the boundary I'd encourage you to keep clean: the page handles agreement, and the payroll platform handles tax paperwork and money. I don't collect a W-9 on my website, and neither should you. I don't want tax identification numbers sitting in my form submissions, and I don't want to be the one responsible for keeping them safe.
So the last section of the standards page says plainly what happens next: you'll get an invitation to my payroll platform — I use Gusto — and that's where the W-9, the signed contractor agreement and direct deposit all happen. Purpose-built software, doing the part it's built for, with the year-end forms handled properly instead of by me in a spreadsheet in January.
The same section states my payment terms, in writing, where nobody can claim they didn't know: invoice me within a week of the event, you're paid in five to seven business days, and no more than two open invoices at a time. That last rule sounds strict and is genuinely there to protect both of us — it stops someone quietly accumulating four months of unbilled work and then presenting it all at once, which is bad for my cash flow and worse for theirs.
Write your standards out first — in a document, in your own words, before you open anything technical. That's the actual work, and no assistant can do it for you because it's a set of decisions about how your studio runs. Once you have the text, open your website's project folder and paste this into Claude Code (or any AI coding agent).