How FigsFlow Changed Our Workflow: One Sterling & Wells Engagement from Enquiry to Open Job

The clearest way to show what changed at Sterling & Wells after we introduced FigsFlow is to follow one of our engagements from beginning to end. We have chosen an ordinary one on purpose. A two-director engineering company in the Midlands, year-end 31 March, VAT stagger 1, payroll for nine people, and self-assessment for both directors. Nothing about it is difficult. That is rather the point. It is the ordinary work that used to leak time, require repeated data entry and depend on individual judgement.

What follows is the workflow as it now runs in FigsFlow, from the first enquiry through scoping, pricing, proposal, engagement, AML/KYC and finally the creation of the jobs that take the client into delivery.

Tuesday Morning, and the Details Nobody Typed

Tuesday, 09:14. The enquiry arrives through our website form and lands in the FigsFlow CRM as a record rather than an email in somebody's inbox. Companies House records are used to fill in the company number, the incorporation date, both directors, the person with significant control and the year end. Nobody types any of it.

That reads like a minor convenience, but it is anything but minor. It is the first change FigsFlow made to the workflow – information enters the practice once and becomes the record used by everything that follows. A record entered once can be relied on by every later step. A record typed into four systems by four people cannot be relied on by any of them, which is why firms end up reconciling their own client data at year-end.

The difference is not simply fewer keystrokes. The next person working on the engagement is starting with the same information as the person who handled the enquiry.

Scoping, Rather Than Quoting

Tuesday, 10:30. A manager scopes the work by selecting from our service library – annual accounts, the CT600, four VAT returns, monthly payroll for nine employees, and two personal tax returns. The pricing engine computes the fee from the factors we configured once, being entity type, turnover band and complexity. It returns £4,320 a year.

He does not decide that number. He decides what is in scope, and the fee follows from it.

That distinction is the whole design of the module, and it is what separates a pricing engine from a calculator somebody keeps in a spreadsheet. Before FigsFlow, pricing depended more heavily on the person preparing the quote. Now the firm's pricing rules sit inside the workflow.

That also means the same scope can produce the same price regardless of who handles it.

Tuesday, 11:40. The proposal goes out, generated from the services already scoped on the record rather than written from scratch. It is opened twice that afternoon, which we can see, because the proposal is tracked rather than attached to an email and forgotten.

The workflow has now moved from enquiry to proposal without somebody copying the client's details into another document, rebuilding the scope or manually checking whether the proposal reflects what was quoted.

The Moment the Price Stops Moving

Thursday, 18:02. Accepted.

The price freezes at that moment and becomes the snapshot everything later is measured against.

This matters because acceptance is no longer simply the point at which someone mentally remembers what was agreed. The accepted scope and fee become part of the engagement record.

The engagement letter then assembles itself clause by clause from the services that were actually accepted, drawn from our clause library. Previously, every letter was a copy of the last letter that looked similar, which meant each one inherited whatever had been slightly wrong with its predecessor.

That is not carelessness. It is what the method guarantees if you repeat it often enough.

With FigsFlow, the engagement letter is generated from the work we have actually scoped and sold. The workflow therefore carries the commercial decision into the legal document rather than asking someone to reproduce it manually.

Friday, before lunch. Both directors verify their identity from their own phones. Standard risk, scored from coded rules, cleared without escalation to our MLRO.

The client has now moved through proposal, acceptance and AML/KYC without those stages becoming separate administrative exercises owned by different people.

Nineteen Jobs that FigsFlow Creates Without Us

Monday, 09:26. The letter is signed. Within the minute, four things happen without anyone touching a keyboard.

The prospect becomes the client on the same record. No second record is created and nothing is re-keyed, so there is no reconciliation to do later and no question about which version is current.

Nineteen jobs are generated from our workflow templates, each carrying its steps, its assignee and its named reviewer.

The statutory dates load against this client's own dates rather than onto a shared calendar: accounts due 31 December 2026, the corporation tax payment date, four VAT quarters on stagger 1, twelve RTI submissions, and two personal returns due 31 January 2027.

And the first invoice is raised from the frozen price snapshot.

That is the point at which the difference between FigsFlow and our previous workflow becomes difficult to miss.

The engagement did not finish with somebody handing a signed letter to an administrator and saying, "Can you set everything up?" The signed engagement triggered the transition into delivery. Four working days from enquiry to open job.

What FigsFlow Changed Beyond the Four-Day Turnaround

Speed was not the problem we set out to solve. Consistency was.

The four-day turnaround is useful because it makes the change visible, but the more important difference is what happens inside those four days.

Before FigsFlow, the workflow depended on people remembering what needed to happen next. Someone had to move information from the enquiry into the CRM, prepare the scope, calculate the price, produce the proposal, prepare the engagement letter, chase the relevant checks, create the client, set up the jobs, enter the deadlines and raise the invoice.

None of those tasks was especially difficult. But together, they created a process with a large number of opportunities for information to be changed, missed or interpreted differently.

FigsFlow turned those handoffs into a connected workflow. The information collected at enquiry feeds the later stages. The selected services drive the proposal. The accepted services drive the engagement letter. The signed engagement triggers client conversion, job creation, deadlines and billing.

The workflow is therefore doing more than saving us administrative time. It is carrying the firm's decisions from one stage to the next without asking somebody to reproduce them.

The Workflow Became the System, Rather Than the People

That is probably the biggest change we have seen.

Before FigsFlow, much of our process existed as knowledge in people's heads. People knew which document to send. They knew which checks needed to happen. They knew which jobs had to be created after the engagement letter was signed. They knew which deadlines mattered. They knew where information had been entered and which spreadsheet or system needed to be updated next.

That knowledge was valuable, but it was also a dependency.

When the process lives mainly in people's heads, adding another person does not necessarily increase capacity. It can increase the number of people who need to be trained before the process works consistently.

With FigsFlow, more of that knowledge is now represented in the workflow itself. The service library holds the services. The pricing rules hold the pricing logic. The clause library holds the engagement wording. The workflow templates hold the delivery steps. The client's own dates drive the statutory deadlines. The accepted scope provides the commercial reference point.

The result is not a practice where people matter less. It is a practice where people spend less time remembering how the practice works.