Every section has an owner, a state and a person waiting on it.
Assignment, comment, review and approval in the place the response is being written — with a version history that says who changed what, and roles that decide who can see the price.
- Produces
- Assignments, threads, approvals, versions
- Enforced
- Server-side, on every request
- Roles
- Owner, admin, manager, member, reviewer, viewer
The response is in the workspace. The conversation about it is in eleven places.
A proposal is written by five or six people who do not share a desk: a capture lead, a solutions architect, a delivery manager, somebody in contracts, a reviewer who appears twice and an executive who appears once at the end. The document lives in one system. The decisions about it live in email, a chat channel, two calendar invitations and a call nobody recorded.
The classic failure is not a lost file. It is a review comment answered privately, so the reviewer never learns whether their objection was accepted; a section that sat with somebody who did not know it was theirs; and an approval given on a version that has since changed.
Colour-team reviews were invented to fix this and they work, but only if the review has a subject: a named section, in a state, with an owner and a deadline. Without that, a review meeting is six people reading a document at once.
- Sections that quietly stallNobody notices an unassigned section until the week of submission, when it is the reason the schedule slips.
- Comments that end nowhereAn objection answered in a direct message closes without a change and reopens at the next review.
- Approvals on the wrong versionA sign-off given on Tuesday against a section that was rewritten on Wednesday is not an approval.
From an outline to an approved response, with the trail intact.
The work moves through states, and every transition is somebody doing something rather than a status somebody typed.
Assign the outline
Each section gets an owner, an internal deadline and the requirements it must answer.
A board where every section has a name against it, and the ones that do not are obvious.
Comment in place
Threads attach to a section, and a thread names the requirement or the claim it is about.
A conversation that stays with the work rather than in an inbox.
Review against the criteria
A reviewer sees the section, the requirements it answers and the evaluation criterion it is scored under.
Review comments that reference the standard the evaluator will apply.
Resolve against a change
A thread closes when the section changes or when the objection is explicitly declined with a reason.
Resolution that means something happened, and a record of what.
Approve, in order
Approval gates run in sequence — compliance, technical, pricing, executive — and later gates open when earlier ones close.
A signed state on a specific version, with who approved what and when.
A board mid-response, one thread that ended in a change, and who can see what.
Eight sections across four lanes, each with an owner and a date. Beside it, a review thread that closed by moving a requirement from partially answered to answered — and the role matrix that decides who sees pricing.
Eight sections, six people, one submission date
- Executive summary
- Price narrative
- Technical approach
- Implementation plan
- Understanding of requirements
- Support model
- Staffing and key personnel
- Past performance
- Reviewer
Paragraph three claims “continuous availability”. The requirement asks for 99.5% measured monthly. Answer the requirement, not the adjective.
- Solutions architect
Rewritten against C.4.2 with the measurement window named and the exclusion list from the service description attached.
- Proposal manager
Resolved. The compliance matrix now shows C.4.2 answered by 2.0 rather than partially answered.
A thread closes against a change, not against agreement: resolving it recorded which requirement moved from partially answered to answered.
Roles are checked on the server on every request. What the interface renders is a consequence of that decision, never the decision itself.
The five roles on a pursuit
- Everything, including pricing and the billing account.
- Every section of every pursuit in the organization, and the decisions behind them.
- The pursuits they are assigned to, and the content library.
- The sections they were asked to review. Not pricing, and not the other pursuits.
- Read-only on what has been shared with them. No comments, no state changes.
The lanes are a static picture of one moment. What matters is that every card has a person, a state and a date, and that no state changes without somebody doing something.
Nothing above is a live query or another customer’s pipeline. Every record in it was written for this page, and no buying organization named in it is real.
What a proposal workspace has to get right.
These are the parts that decide whether a team abandons the tool and goes back to email.
Ownership per section
Every section has one owner and one state. Shared ownership is how a section ends up owned by nobody.
Threads that resolve into changes
A thread closes against an edit or an explicit declination with a reason, so “resolved” is a fact rather than a mood.
Sequenced approval gates
Compliance, technical, pricing and executive review in an order, with a later gate opening only when the earlier one closes.
Version history that names people
Who changed what and when, on every section, so an approval can be checked against the version it was given on.
Roles that hide what should be hidden
A reviewer brought in for the technical volume does not see pricing. Eight roles, checked on the server, never inferred from what the interface rendered.
An audit trail that only grows
Security-relevant events are written append-only: added, never edited, never quietly removed.
Where the coordination is the hard part.
Three shapes of team for which the workspace matters more than the drafting.
A distributed bid team
- Contributors in three time zones, none of whom are in the same meeting, and a submission date that does not move.
- Section ownership with internal deadlines, threads in place, and approval gates in sequence.
- Handovers happen against a board rather than in a status call somebody has to attend at six in the morning.
A firm that uses external reviewers
- Brings in subject-matter reviewers and a former evaluator for colour-team reviews, and cannot show them the whole pursuit.
- The reviewer role, scoped to the sections they were asked to review, with pricing out of reach.
- Outside review without a confidentiality conversation, because the access boundary is enforced rather than agreed.
A regulated organization
- Needs to show who approved what, on which version, months after submission.
- Sequenced gates, version history and the append-only trail, exported alongside the submission.
- An answer to “who signed this off” that does not depend on somebody’s sent-items folder.
Seats and approvals are what step here.
Assignment, comments, version history and roles are part of every plan. Formal approval workflow — gates that must be signed before a response can proceed — and advanced permissions arrive with Business.
- Every plan includes assignment, threads, version history and the role model.
- Seats rise with each plan, from a small team to a delivery organization.
- Business and above add approval workflow and advanced permissions.
- Agency adds client workspaces, so work for different clients is kept apart rather than filtered.
Plan names and allowances are mirrored from the billing catalog. Amounts are on the pricing page, which reads them from Stripe rather than from a number typed into a marketing page.
What people ask about collaboration.
What are the roles?
Owner, admin, billing admin, manager, member, reviewer and viewer, plus a platform super-admin that belongs to us rather than to a customer. Every one of them is checked on the server on every request; what the interface shows is a consequence of that decision and never the decision itself.
Can we bring in a reviewer who should not see everything?
Yes — that is what the reviewer role is for. It is scoped to the sections they were asked to review and excludes pricing and the other pursuits in the organization.
Does it replace our review process?
No, it gives the process a subject. Whatever your colour-team or gate review is called, it becomes a state on a named section with an owner and a date, which is what makes a review meeting about the work rather than about status.
What does the version history record?
Who changed which section, when, and what the section looked like before. Approvals are recorded against a specific version, so a sign-off given on a version that has since changed can be seen for what it is.
Do we need the approval workflow?
Only if your process needs a signature to be enforced rather than expected. On lower plans the states, the ownership and the trail are all there; what Business adds is the gate that will not let a response proceed until somebody with the right role has approved it.
Put one live response on a board.
Take a pursuit currently running in email, give every section an owner and a state, and see how much of the status conversation stops being necessary.