From SOP to Agent: How a Written Process Becomes Something Copilot Studio Can Run

Everyone says document your processes first. Almost nobody says what the document has to contain, which is why so many firms arrive with a neat procedure and leave the first conversation realising it describes about half of what actually happens. This post shows the transformation on one process, the engagement letter, from the page on the shared drive to the version Copilot Studio can run. The thing to take away is that the exceptions and the approvals are the specification, and they are the parts nobody has written down.

The before version below is a typical firm’s, written to be recognisable rather than taken from anywhere. The after version reflects what we have built. Where a step is the next phase rather than live, it says so.

The procedure as it usually exists

Here is the engagement letter SOP, more or less as it sits in most practices’ procedures folder.

1. Partner agrees services and fee basis with the client.
2. Partner emails business support with the details.
3. Business support opens the template, fills in the client details, selects the service paragraphs and adjusts the fees.
4. Draft sent to the partner for review.
5. Partner amends or approves.
6. Letter sent to the client for signature.
7. Signed copy filed. Client record updated with the services. Onboarding checklist started.

Seven steps, one page, and it is not wrong. It is just not the process. Sit with the people who do it and ask what happens when there are two signatories. When the client is a group of companies. When the client is not yet a client and has no record to update. When the partner is away. When KYC has not cleared. When the client signs, but with a change in the margin. Who decides the fee when the standard rate does not apply. Where the letter waits at each step, and for how long, and who notices when it has waited too long.

The honest answer to most of those is “it depends who is doing it that week”. That answer is not a criticism of the firm. It is the reason the process cannot be automated yet. A flow needs to know what to do with two signatories every time, not the way whoever is in that week does it.

The five questions Discover asks

Discover is not a technical audit. It is time spent with the people doing the work, mapping the workflow as it actually runs, and five questions do most of the reshaping.

What varies between one run and the next? Client, services, fee basis, signatories, group structure. Those become form fields, and the form becomes the way the process starts.

What is copied from somewhere else? Client address, company number, partner name, last year’s scope. Those become lookups, pulled from the system that holds them rather than retyped.

Who decides, and what do they decide on? The partner decides the terms. Business support checks the details. KYC clears the client. Those become approval steps with defined inputs, so each approver sees what they need to decide and nothing else.

Where does it wait, and why? In the partner’s inbox. In the client’s inbox. In a folder waiting for KYC. Those become triggers and notifications, or they get removed altogether when the waiting turns out to serve no purpose.

What goes wrong, and what does someone do when it does? The two-signatory case, the group, the non-client, the signed-with-changes letter. Those become the exception paths and, for anything that does not fit a path, the review queue.

The output of Discover is the answers. The output of Design is what the answers become: the workflow map with every step labelled, the recommended build route and a fixed price, played back in a session of about an hour. The FiveForward Framework page shows where the two stages sit in the five.

The same procedure after Design

Here is the engagement letter again, with each step labelled by who or what does it. Three kinds of step: a flow does it, an agent drafts it or a person decides it.

1. Form (person). The partner or business support completes one form: client, services, fee basis, signatories, group companies if any, KYC status. The form asks the questions in order, every time.
2. Lookup (flow). Client details are pulled from the practice system. If the client does not exist yet, the non-client path creates the record first.
3. Draft (agent, or a template merge where the wording is fixed). The engagement letter is generated from the firm’s own template with the selected service paragraphs and fee wording. In the next phase, the same request also produces the risk assessment and the fact find.
4. Approval chain (flow with people in it). Business support check, partner approval, KYC clearance. Each is a Teams approval with the draft attached. Nothing proceeds until all three have said yes, and each approval is timestamped.
5. Send and sign (flow plus person). The letter goes for signature. The signed date is captured when it comes back.
6. Record update (flow, gated). Services are written to the client record only once the signed date is populated. This detail is real and worth a sentence: the record reflects what the client signed, not what was proposed.
7. File (flow). The PDF is filed to the document management system and the document reference stored back on the client record. The status is visible throughout, so “where is the letter” has an answer without asking anyone.

Evidence status, plainly. The form, the background generation, the review before sending and the change from 30 to 60 minutes of assembly to a few minutes of form filling are delivered, at a practice we work with, and the form-and-flow version is written up in our engagement letter automation example. The three-document output, the approval chain with KYC, the non-client path, the signed-date gate and the PDF and document reference on the record are the next phase, in progress. They are described above as the shape that phase takes, not as live.

On the labels. Steps 2, 4, 5, 6 and 7 are flows because they should behave identically every time, and the line between that and an agent step is the subject of Copilot Studio vs Power Automate. Step 3 is where wording varies, which is what a drafting agent is for. The newer Workflows Designer in Copilot Studio lets both kinds of step sit on one canvas, which makes a map like this easier to build as drawn. The post pipeline in one letter, two minutes is the same three labels applied to incoming correspondence.

What changed

Four things, none of them the technology.

The form became the SOP. There is no longer a page in a shared drive that may or may not be followed. The form asks the questions, in order, every time, and a run that skips a question cannot start. The procedure is enforced by the fact that it is the only way in.

The approvals became visible. “Waiting for the partner” was invisible before. Now it is a status with a timestamp, and the person who set the process running can see where it is without asking. This alone changes behaviour, because a letter that has waited three days is visible to everyone rather than to nobody.

The exceptions got a path. Group companies, multiple signatories and non-clients used to be handled by whoever knew how. Now each has a defined branch. Anything outside the branches stops and asks a person, which is the same rule the post pipeline runs on: when unsure, route to a person rather than guess.

The time moved. Thirty to sixty minutes of assembling became a few minutes of form filling and a review. The partner’s time did not go down much. It moved from amending a draft to approving one, and the approval is the control point, not a formality. That is the honest description of what automation does to a partner’s role: it changes the shape of the work rather than removing it.

What this means for your own SOP

If your firm wants a process ready for Discover, the useful preparation is not rewriting the procedure. The polished version is the least informative document you have. What is worth an hour is listing the exceptions and the approvals honestly, and three prompts get most of it out.

Write down the last five times this process went wrong, and what someone did about it. Write down who approved the last ten runs and how long each one waited at each step. Write down everything that gets copied from somewhere else, and where from.

That list is the specification. It is worth more than the procedure, and it is what the first Discover conversation would spend its time trying to reconstruct. The engagement letter is one of five admin jobs an agent can take off a practice, and the same three prompts work for every one of them.

Two routes to the running version

From the map, the build goes one of two ways, chosen at the Design playback. On route one we map and build it: Discover at £1,500, credited back once follow-on spend passes £3,500 before VAT within 90 days of the roadmap, then a fixed-price build at Automate, typically £5,000 to £15,000. On route two we teach your own people to do the mapping and the building: £3,950 fixed, two delivery days through Enable, two build reviews and 90 days of async support, working on your own processes rather than an example like this one.

Whichever route, the running version needs an owner from the day it goes live, because the form, the approvals and the connectors all move. What happens after the agent is built is about who that is.