Your proposal tool ends at the signature. The work starts there.
You already win work properly — priced, scoped, signed, on time. Then the client says yes, and everything after that moment goes back to a spreadsheet, an inbox and somebody's memory. The gap isn't in how you sell. It's in the handover.
who remembers
Sits on the stack your firm already runs
Entra ID SSO, Outlook, Teams and Graph.
Client documents stay in your own tenant.
The ledger stays where it is.
Payment events land on the record.
For wiring your proposal tool in yourself.
Counts describe the shape of a standard engagement, not a benchmark or a research finding.
Keep the tool. It isn't the problem.
Proposal software solved something real, and firms that adopted it stopped underpricing and stopped rewriting scope from scratch. Nothing here suggests ripping it out. The question is narrower: what picks the work up once the client has signed?
Winning the engagement
The part of the firm that has a system, a template and an owner.
- Pricing that isn't guessed at on a Friday afternoon.
- Scope written once and reused rather than rebuilt per client.
- Signature captured properly, with a record of what was agreed.
Doing the engagement
The part that runs on memory, chase emails and a shared spreadsheet.
- Kickoff that only happens when someone notices the signature landed.
- Records requested by email, chased by hand, filed wherever.
- Billing reconciled against a scope living in a different system.
Five stops, and the seam sits at the first one
Watch where the automatic part stops and the manual part begins. Everything downstream inherits that delay, because nothing downstream knows the engagement exists yet.
Client accepts
The proposal tool does its job. Scope and fee are agreed and signed.
handledSomeone notices
The acceptance sits in one system. The job gets created when a person opens the other one.
manual seamWork is set up
Tasks, owner and deadline get written out again, from the scope that was already agreed.
re-keyedRecords are chased
An email, then a private follow-up schedule that lives in one person's head.
unownedThe bill is checked
Hours in one place, agreed fee in another. Scope creep is discovered a month late.
reconciledFour moments your proposal tool can't reach
Pick a moment to see what usually happens after the engagement is won, and what changes when the practice side sits in the same system as the work.
Nothing, until somebody checks
The acceptance sits in the proposal tool. The job gets created when a person notices and opens a spreadsheet. Between those two events the client believes work has started, and no dashboard disagrees.
Acceptance opens the job
The engagement, its tasks and its owner exist the moment the letter is signed — because the thing that captured the signature is the thing that runs the work.
An email, then four more
Someone writes the list of what's needed, sends it, and starts a private chase schedule. The client replies with three of the seven items and an attachment nobody files.
One request, chased for you
The client gets a single structured request tied to the engagement, follow-ups go out without anyone remembering, and what comes back lands against the job rather than in an inbox.
Status is a question you ask a person
Where the job stands lives with whoever is doing it. Partners find out at the meeting, and capacity is a feeling rather than a number.
Stage, owner and deadline on the record
The same workflow runs every engagement of that type, so status is a screen instead of a conversation, and workload is visible before it becomes a problem.
Scope is checked from memory
The agreed fee is in the proposal tool. The hours are somewhere else. Whether the work stayed in scope gets decided a month late, never on evidence.
Time sits against the engagement it belongs to
Out-of-scope work is visible while it is happening rather than at billing, so the conversation with the client is about a variation, not an apology.
The half of the engagement nobody sold you software for
Parts of one system, reading the same client and the same job — not connectors bolted between two products.
Jobs, tasks and deadlines
Every engagement runs the workflow its type deserves, with an owner and a date that someone can actually be held to.
Jobs and workflowClient portal and requests
One place for the client to go, chased automatically, and filed straight to the engagement it belongs to.
Client portalAnd it fits the stack you already run
Documents can stay in your own SharePoint rather than moving to a second store, with Microsoft 365 underneath the rest. Where you need to connect something yourself there is an API and webhooks — access is opening with the founding-customer group rather than generally available today. What connects right now is listed plainly on the integrations page.
Add the practice side, or bring the proposal in too
Both are real choices and firms make each of them. The difference is whether you are willing to move the part that already works — not whether one is more advanced than the other.
Keep your proposal tool
Add practice management underneath it and change nothing about how you win work.
- Nothing to relearn for the people who price and send.
- Delivery, records, time and billing all get a system.
- You can consolidate later, once the practice side has proved itself.
- The handover from proposal to job stays manual unless you wire the two together yourself.
- Two subscriptions, and scope still lives somewhere other than the work.
Bring the proposal in too
Price, propose, sign and run the work on one record, and retire the separate tool.
- Acceptance opens the job automatically — no handover step at all.
- The signed scope and the delivered work are the same object.
- One subscription instead of two.
- Your team relearns the pricing and proposal step, which is real change management.
- Worth checking your must-have proposal features exist before committing.
Add it underneath, without pausing the work you've won
A FigsFlow specialist handles the migration during onboarding, so clients and open engagements move once rather than being exported and re-imported by your team. Your proposal tool stays live throughout.
Bring the clients across
Client records and open engagements move once, with help, during onboarding.
Set up one workflow
Pick the engagement type you run most and build its template. Don't model everything on day one.
Run new work through it
Keep signing in your proposal tool. New engagements land here and get delivered here.
Decide about the proposal step
Once delivery is steady, choose Path A or Path B with evidence rather than a guess.
See an engagement go from signed to delivered
Illustrative interface — see the real thing on a demo
“
[ Practitioner quote about adding practice management alongside an existing proposal tool — held empty until a named practitioner is cleared for use. ]
[ Name ] · [ Role ] · [ Firm size ] · [ State ]
What firms with a proposal tool ask first
Do I have to give up my proposal tool?+
If I keep my proposal tool, does the job get created automatically?+
What happens to the clients and engagements already in my systems?+
How long before this is actually running?+
Is this built for US firms specifically?+
You've solved winning the work. Solve doing it.
Bring your proposal process to the demo. We'll walk both paths and tell you honestly which one your firm should take.
Start Smarter. Grow Faster.
From proposals to pricing, streamline every step with automation designed particularly for accountants, bookkeepers and tax advisers.