Data centre documents get read by people whose interests do not align. A colocation customer wants to know exactly what uptime they are being promised and what happens when it is missed. An insurer wants the fire suppression and flood risk detail. A planning authority wants water consumption and grid impact. A technician at four in the morning wants to know which breaker to pull. One organisation writes for all of them, often reusing the same paragraphs, and the sentence that satisfies the sales cycle is frequently the one that causes trouble in the service credit dispute two years later.

We edit what data centre operators and their customers produce — colocation and service level agreements, uptime and availability commitments, site selection and feasibility studies, planning and environmental impact submissions, capacity and power density documentation, cooling and thermal management specifications, sustainability and energy efficiency reporting, standard operating procedures and method statements, change management and maintenance windows notices, security and access control policies, disaster recovery and continuity plans, audit evidence for uptime and compliance certifications, tenant handbooks, and incident and outage reports. Our editors check that availability figures, measurement windows and exclusions are stated consistently across the commercial and technical documents, because in most contracts they are not.

The service level agreement is where imprecision becomes expensive. "99.99% uptime" is not a commitment until the document says what is being measured, over what period, from whose monitoring, and what is excluded — and most disputes turn on exclusions written so broadly that the guarantee dissolves. We rewrite these so availability is defined against a named measurement point, the period is stated as monthly or annual rather than left implied, planned maintenance is bounded by hours and notice rather than merely excluded, and the service credit process names the deadline and the evidence a customer must supply. We also make the definition of an outage explicit, including the partial-degradation case that operators and customers reliably read in opposite directions. A tighter SLA is not a weaker one; it is the version both parties can still agree on after something has gone wrong.

Everything you send is treated confidentially, including site plans, security procedures and outage documentation. Whether you are an operator preparing customer-facing agreements, a consultancy writing a feasibility study, or a team assembling a planning submission that non-specialists will assess, we can make the writing exact and internally consistent.