A statement of work in under an hour
A company evaluating an AI proof of concept asked me last month how we write our statements of work. Not the pricing. The document itself. Every SOW on their side is built by hand, there is no CPQ for services, and the head of their professional services group put the problem in one sentence: “How do you make it feel personalized to them without agreeing to like 85 ad hoc things?”
I had an answer, because we had already solved it for ourselves. This is the written version of what I walked them through.
What a statement of work used to cost
Writing the SOW for a mid-sized implementation used to take me 12 to 16 hours. Two working days for the person who is supposed to be running the firm, sitting in Word, pulling numbers out of the quote by hand, finding the last SOW that looked something like this one, keeping the sections that still applied and rewriting the ones that did not, and then reading the whole thing a third time because the pricing table and the phase list have a way of drifting apart when you touch one and forget the other.
Most professional services firms I sit down with are doing some version of that. Nobody quite trusts the template, and the person who writes the best SOWs is also the person with the least time to write them. So the document is either generic and fast or personalized and slow, and the client can tell which one they got.
What it costs now
The same SOW now takes me less than an hour end to end. Under sixty minutes from the opportunity in Salesforce to a branded document out the door for signature. That is the standard case, and there is a range on either side of it. A simple one, a renewal on a managed-service engagement where the shape is already settled, I have done in under twelve minutes. A complex one, the kind with a requirements document and a lot of parts that have to be pulled in, merged and iterated, takes a few hours. Put that last one next to the alternative: by hand, a document like that would not have come off my desk in under a day, and it would have been my day.
I lead with the hour and not the twelve minutes because the hour is the typical case. But a few hours for the hardest SOW we write is not the caveat on the number. It is the part of the number I would show a skeptic first, because it is where the old way was worst.
We run AI agents inside our own systems, built on the same tools we implement for clients. How they are built is a different post. This one is about what the SOW process looks like from my chair.
The opportunity exists in Salesforce, the way it always has. The quote gets built in our quoting tool, scoped by phase and by level, and I dial in the numbers myself because that part is judgment. When the numbers are right, I ask for the statement of work. It comes back as a draft, structured the way our SOWs are structured, with the account, the phases and the pricing already in it, and I read it the way I would read a draft from a good associate: mark it up, send it back, read it again. When I am happy with it, it becomes a branded Word document with the right name on it, filed in the right folder, and out the door for signature. When the signed copy comes back, it gets filed and indexed too, and I never open a folder.
None of those steps is new; I was already doing every one of them. What changed is that I now do the two that need me, the numbers and the review, and the rest happens the same way every time. The old SOWs were fast or careful depending on the week. These are the same on a good week and a bad one.
The part the client actually asked about
Speed was not the question on that call. The question was personalization, and it came up in their words twice before I had said anything about ours. Anyone can produce a fast generic SOW. The hard thing is a document that reads as written for this client, in their language, covering the sections they asked for, and still holds the line on scope so that the eighty-five ad hoc things become change orders rather than surprises.
This is where the time saving turns into something else. If the client sends a requirements document, or an RFP with four sections they want addressed by name, I hand it over and those sections get pulled in where they belong, in the client’s terms, inside our structure. PDF, Word, Excel, PowerPoint, I do not care what it arrives as. I used to skip that step when I was short on time, which was always. Now it is the cheapest part of the job.
So the SOW that used to be fast or personalized is now both, and the more useful consequence is on the scope side. When the document reflects what the client actually asked for, the boundary is clearer, and the change-order conversation three months later starts from a sentence they recognize instead of one they skimmed.
What I would tell a firm starting from manual
Frankly, the templates are the work. We keep five templates, built from our own signed SOWs, and getting them right took real time up front. The generation is the easy part once the firm has decided what a good SOW of each kind looks like. A firm that skips that step gets fast documents that all read the same, which is the problem it started with, only quicker.
The number that matters
The number that gets attention is the twelve minutes, and it is true, for the simple ones. The one I care about is that the document comes out the same way every time and reads as written for the client who is signing it. The work is the same as it was. The time goes to the two parts that were always mine.
Related Articles
Connecting an agent to your systems is now a switch. What still decides how far it reaches.
AI pilots rarely stall at the model. They stall at the data, process, and governance underneath it.
Pure build is rarely practical. Pure buy is rarely enough. The sequence that works.
About The Author
