Workflow Playbook: Assembling Client Proposals from Mixed Source Files

This is a worked example rather than a client case study. It describes a document assembly problem that recurs across small agencies, consultancies, and professional services firms, along with the specific failure modes and the workflow that addresses them. No named client engagement or measured result is being reported.

The scenario: a team of roughly a dozen people preparing a competitive proposal on a short deadline. The content already exists. A designer has produced a narrative deck, a finance lead has a budget spreadsheet, an account director has a scope and terms document, and someone has collected three case studies. The task is to deliver all of it as one professional file, to a client, by a specific hour.

Assembling a proposal is not difficult because of any single step. It is difficult because the sources come from different applications, each with its own idea of what a page is.

A presentation exports to a landscape page, usually at a widescreen aspect ratio, and often with full-bleed imagery. A spreadsheet exports to a landscape page at a different size, and frequently splits across multiple pages in ways nobody intended. A word processing document exports to portrait A4 or Letter. Three sources therefore produce three page sizes and two orientations, and the assembled document looks like exactly what it is: several files stapled together.

The second problem is file size. Presentation exports are image-heavy, and a twenty-slide deck exported with full-resolution imagery can exceed a typical email gateway limit on its own. Adding a spreadsheet and a legal document on top makes an attachment that will be rejected, which is discovered at the worst possible moment.

The third problem is confidentiality. A proposal contains pricing, commercial terms, and unreleased creative direction. It is precisely the category of document that should not be uploaded to an unvetted web service, and the deadline is precisely when people stop caring about that.

The sequence below is ordered so that the expensive steps happen once, on the finished artefact.

The failure modes are consistent enough to check for specifically.

Proposal documents sit in an awkward category: valuable to the firm, sensitive to the client, and frequently containing personal data in the form of contact names and roles.

This is the practical argument for keeping the assembly local. Every step in the workflow above is a structural operation on a file: merging, reordering, rotating, removing pages, recompressing. None of them requires a server, and all of them run in the browser in seconds. Uploading a proposal to a third-party converter introduces a disclosure and a delay for no benefit whatsoever.

There is a second consideration that is easy to overlook. If the assembled document is sent to a client, and the client forwards it internally, the document now contains metadata describing who created it and with what software. Stripping document properties as part of the final compression step is a small, cheap precaution. The privacy guide covers the wider set of questions worth asking.

One further point on scope. If the proposal contains genuinely sensitive material such as named references or commercially confidential figures that must be removed before sharing, note that covering text is not removal. The redaction guide explains why, and it is worth reading before you assume a black box has done the job.

The same pattern applies to any task where several documents from different applications must become one deliverable.

The elements that matter are consistent: normalise the sources before combining them, name them so the order is unambiguous, verify each source individually, combine once, then optimise and verify the finished artefact. The specific tools change with the task, but the sequence does not.

The other transferable habit is to treat file size as a delivery constraint rather than an aesthetic one. Knowing the limit of the channel before you start determines whether you can fix a large file by compressing it or whether you need to change how the source was exported. Discovering the limit at the point of sending is the failure this habit prevents.