A composite customer conversation, and the backlog decision it would drive

Composite. This is not a transcript of one call — it is a distillation of the conversations we have been having with mid-market proposal teams during product development. Names, seat counts, and specifics have been changed or combined. The pattern the post describes is real; the “one customer” framing is a narrative device.

I spend part of most weeks talking with proposal teams who are designing against the product — the operators we are building toward, not a catalog of paying tenants. One pattern has been recurring in those conversations clearly enough to change a decision in the backlog, so I am writing up the composite shape of it while it is fresh.

The kind of operation we are building toward: a mid-market proposal team, roughly the size of a color-team rotation, responding to a steady flow of proposals a year across two verticals. A team at that size cares more about throughput-per-SME than about headcount expansion, and they are explicit about it.

The workflow pattern I keep hearing described: teams use a drafting pipeline for their first pass, edit the draft, run a color-team review, and then — this is the part that keeps surprising me — paste the reviewed draft back into the drafting pipeline and ask it to re-align the citations. The round-trip takes a meaningful chunk of manual work per section, and teams do it because color-team edits frequently move content between paragraphs in ways that break the original citation anchors.

The surface request is usually for citation anchors that are more resilient to paragraph-level edits. That is not the interesting part of the conversation. The interesting part is that teams are inventing the round-trip workflow because they don’t know the product has a lower-friction way to handle the problem. There is a post-review re-grounding step. It does exactly what they are doing manually. It is behind a menu that is easy to miss.

So the decision this pattern changes is not about resilient citation anchors. It is about the discoverability of the post-review re-grounding step. That feature has been in the product for some months and its usage rate is lower than we would like, which I now suspect is mostly an education and surfacing problem rather than a feature-fit problem. The lower the usage rate on a specific feature, the more likely the issue is that users do not know it exists.

What this moves forward in the backlog:

First, the post-review re-grounding step surfaces as an inline action on the draft itself when the system detects that the draft has been edited outside the drafting pipeline. The detection is already in place for other reasons; using it to prompt the re-grounding is new.

Second, the feature gets a walkthrough in the guided onboarding for new customers. The onboarding has three checkpoints currently; this becomes a fourth.

Third, the usage metric moves to the operator dashboard as a tracked number. If we ship these changes and the usage rate does not move meaningfully in the following sixty days, the hypothesis is wrong and we need to revisit.

That is the whole post. A composite conversation, a backlog change that keeps surfacing across many real ones.