Enterprise software is sold through documents and implemented through documents, and the two sets rarely agree. A statement of work says the integration will be delivered; the sales deck implied it was included; the customer's project manager reads both and forms a third understanding. Eighteen months later, when the programme is late, everyone returns to the wording. In a sector where a single deal takes nine months and a dozen people to close, the writing is not supporting material — it is the mechanism by which expectations are set and, eventually, disputed.

We edit what enterprise vendors and their customers produce — statements of work and scoping documents, implementation and deployment plans, requests for proposal and the responses to them, security and vendor risk questionnaires, master service agreements and support terms, functional and technical specifications, configuration and administration documentation, end-user training material and adoption guides, change management and communications plans for rollouts, integration documentation for connected systems, business cases and executive briefing papers, and quarterly business review material. Our editors check that scope language is consistent between the commercial and technical documents, and that what is included, excluded and dependent on the customer is stated in terms that will still be clear to someone who joins the project later.

The statement of work is where careful writing pays for itself repeatedly. Most are generous with deliverables and silent on assumptions, which means every dependency the customer fails to meet becomes the vendor's problem in practice if not in contract. We rewrite them so deliverables are described by their acceptance criteria rather than their activity — "a configured environment that passes the twelve test cases in Appendix B" instead of "configuration of the environment" — and so customer dependencies are listed with dates and named owners rather than gathered into a paragraph of assumptions nobody reads. We also make the change control route explicit and easy, because a project with a painful change process does not stop changing; it simply stops recording the changes, which is how the scope dispute at the end becomes unresolvable.

Everything you send is treated in confidence, including commercial terms, customer names and implementation documents under agreement. Whether you are a vendor standardising documents across a delivery team, a customer trying to understand what you have actually been offered, or a bid team writing under deadline, we can make the language precise, consistent and defensible.