21WSOLInternal tool

Our own proposal and sales-document system.

A component library, version handling and pre-dispatch checks — the internal process every WSOL proposal is built in.

Client
WSOL
Type
Internal tool
  • Component library
  • Version handling
  • Pre-dispatch checks
An abstract cover of the workflow steps — not a capture of the system.

Context

Every proposal WSOL sends is assembled from the same parts: a scope, a prior case, a pricing structure and a version that has to match what was actually said in the room. Held in loose files, that work gets retyped every time. This is the internal system that made it one process.

The challenge

A proposal is not one document. It carries a scope, a case reference, a delivery boundary, a pricing structure and a version that has to match what was agreed in conversation. When those live in separate files, every new proposal starts by hunting down the closest previous one and copying from it. Wording drifts between versions, an old scope line survives into a new offer, and nobody can say with certainty which document is current.

Our work

One working process: intake · scope · assemble · review · dispatch. Proposals, cases, scope blocks and sales documents sit in one library instead of in files. Text is composed from reusable components rather than retyped, so a scope clause or a project description has a single source. Versions are tracked, validation runs before a document leaves, and the file the client receives is generated from the same structure that feeds the internal record.

What was built

Component library
Scope clauses, case descriptions and pricing blocks are stored once and composed into a document, instead of copied out of the previous proposal.
Version and lineage
Every proposal carries a version and a lineage, so the current document is identifiable and rejected wording does not leak forward into new offers.
Pre-dispatch validation
Structural checks run before a document leaves: required blocks present, scope and pricing consistent, no leftover text from the source it was built from.
Concept to delivery
One process from the first scoping note to the file the client receives, with the internal record and the sent document generated from the same structure.

How the process looks

Before

  • Every proposal starts by copying the last one
  • Wording drifts between versions
  • Nobody is sure which version is current

With the system

  1. Intake
  2. Scope
  3. Assemble
  4. Review
  5. Dispatch

The evidence

No system captures have been cleared for publication yet. This page describes what was built and how it works, without passing off a mock-up as a real screen.

Scope boundary

This is a capability record, not a results claim. We describe the system and how work moves through it: the component library, version handling, validation and the path from concept to client delivery. We publish no number for time saved, win rate or proposal volume, because we hold no measurement we would stand behind. What we can state plainly: WSOL's own sales operation runs on it, the same class of system we build for clients. Proof over promises starts here.

A similar project in your business?

Tell us where the work gets stuck today, and we'll look together at what makes sense to build, connect or improve.