One record, two directions

Introduction#

A consultancy that sells to the public sector acquires work two ways in the same week. It hunts published tenders^[1], and it receives approaches - sub-consultants proposing a partnership, sponsors sending a business plan, clients forwarding an RFP. Most software does one of these. Tender aggregators stop at the alert; intake forms stop at a PDF in a shared inbox.

Running them separately is workable until somebody asks how many bids the firm ran last quarter, at which point there are two answers and both are defensible. We built one pipeline instead. This post describes how the two directions converge and what that costs.

The two paths#

On the outbound side, a tender that clears the shortlist becomes a workspace in one action, with team members whose CVs match the required capabilities attached automatically. Declining records a structured no-go rather than removing the row, which is what makes the pipeline auditable afterwards - a firm can ask what it passed on and why.

On the inbound side, applicants submit through a portal on the firm own subdomain, either by completing a form the firm configured or by chatting with an intake assistant that normalises a free-form description into the required fields. Attached documents are parsed and extracted into structured project data on arrival. The submission is then scored by the same ensemble that ranks discovered tenders, with evidence snippets pairing a firm capability against an applicant requirement, and both directions carry the same CPV sector classification^[2].

The shared promotion step#

Accepting an inbound project runs the identical promotion stack as developing a discovered tender. Not an equivalent one - the same one. Acceptance resolves the applicant as an issuer, assigns the accepting user as bid manager, seeds a checklist template, creates the proposal row, pre-populates the expression-of-interest fields, writes an approved decision record and notifies the applicant.

The result is that a firm pipeline, its records ledger and its analytics never need to know how an opportunity entered the building. There is one definition of a bid in progress, one place win history accumulates, and one number at the end of the quarter.

Discussion#

Limitations#

Convergence is a constraint as much as a feature, and it costs on the inbound side. The workspace was designed for a public tender: it expects a deadline, an issuing authority, a requirement list extracted from tender text. An inbound approach frequently has none of those - a partner proposing a collaboration has no deadline and is not an issuing authority in any meaningful sense - and it is resolved into that shape anyway. The abstraction fits the outbound case better than the inbound one, and we chose that deliberately rather than maintaining two.

The scoring assumption transfers less well than the object model does. Ranking a published tender against a firm profile asks whether the firm can deliver the work. Ranking an inbound application asks something closer to whether the firm should take it on, which involves commercial judgement the ensemble does not model at all. We use the same signals for both because they are the signals we have, not because we have shown they are the right ones for triage.

The promotion steps are best-effort individually. A promotion where the checklist template seeds but the applicant notification fails leaves a workspace that exists and an applicant who has not been told, and reconciling that is currently a human noticing.

The argument for convergence in this post is a design argument, not a measured result. We assert that one pipeline produces one answer to "how many bids did we run" and that two would produce two, which is true by construction and says nothing about whether firms are better off. We have not compared against firms running separate systems, we do not measure how often the shared abstraction forces an awkward fit on an inbound approach, and we would not know from our own telemetry if it did - a bid manager working around the model looks identical to one using it.

What we would change first#

Giving inbound its own scoring objective, rather than borrowing the outbound one. Ranking a published tender asks whether a firm can deliver the work; triaging an approach asks whether it should take it on, and those want different signals. The change is not hard and we have not made it because we lack the labelled triage decisions to tell whether a separate objective would be better or merely different.

Second, making a partial promotion visible. The steps are already recorded individually, so surfacing a promotion that did not complete is a reporting change rather than an architectural one, and it removes the one failure here that currently depends on somebody noticing.

Conclusion#

Two acquisition paths, one workspace object, one promotion stack shared between them. The convergence is what makes a single pipeline number meaningful, and the price is an abstraction shaped by the outbound case that the inbound case has to fit into. Whether that trade is the right one for a given firm is a question we can argue but have not measured.