83,229
edits
Plain English - Organise: Difference between revisions
no edit summary
Amwelladmin (talk | contribs) No edit summary |
Amwelladmin (talk | contribs) No edit summary |
||
| (2 intermediate revisions by the same user not shown) | |||
| Line 4: | Line 4: | ||
== Organise == | == Organise == | ||
=== | ===Tone=== | ||
'''Client-centric''': Structure your document to be as ''[[persuasive]]'' as possible. Persuasive to who? The client. You do not need to persuade ''your own risk department'' to sign your own document.<ref>OK this is not necessarily true, but you ''should not need to''.</ref> You ''do'' need to persuade the customer to sign it. Therefore: | '''Client-centric''': Structure your document to be as ''[[persuasive]]'' as possible. Persuasive to who? The client. You do not need to persuade ''your own risk department'' to sign your own document.<ref>OK this is not necessarily true, but you ''should not need to''.</ref> You ''do'' need to persuade the customer to sign it. Therefore: | ||
* '''Make the customer feel wanted'''. | * '''Make the customer feel wanted'''. | ||
** '''Be enthusiastic''': Little things: write, “Welcome!” in big, friendly letters at the start. Have a recital recording how ''thrilled'' your firm is to be doing business with it. Why not? | ** '''Be enthusiastic''': Little things: write, “Welcome!” in big, friendly letters at the start. Have a recital recording how ''thrilled'' your firm is to be doing business with it. Why not? | ||
| Line 15: | Line 13: | ||
*** Instead of, “''in the event that Client fails to ...,''” say, “''if you do not ...''”. | *** Instead of, “''in the event that Client fails to ...,''” say, “''if you do not ...''”. | ||
*** Instead of, “''the client shall forthwith upon written demand indemnify Lender''” say, “''you must promptly reimburse us if ...''”. | *** Instead of, “''the client shall forthwith upon written demand indemnify Lender''” say, “''you must promptly reimburse us if ...''”. | ||
=== Order === | |||
* '''Fun stuff first''': Put terms that are most important to the client first. What are you going to do for the customer? What are the customer’s key benefits? What are its objectives? Get this in first. Make the customer’s first reaction, when it sees the draft, “YES!” Tick! Make its ''second'' reaction also a TICK! ''Have the customer thinking happy thoughts about you and this document''. | |||
* '''Nasty stuff last''': Put the terms ''you'' care most about — your fees, default events, [[indemnities]], what could happen if the customer blows up, etc. — ''last'' (or at least, last before the boring [[boilerplate]]). Legally, the sequence of the clauses doesn’t matter. Psychologically, it matters a lot. ''Put the fun stuff first''. Have the customer in a maximum, dopamine-flooded haze of benign fondness towards you by the time it gets to the [[events of default]]. It won’t last, but the more good will you have, the better you will fare. | |||
'''Boilerplate''': Organise the boilerplate the same way. | '''Boilerplate''': Organise the boilerplate the same way. | ||
* '''General principles''': Where there are general principles that clients might like (“[[commercial reasonableness]]” standard of prudent conduct, general application of laws and so on) put these first. | * '''General principles''': Where there are general principles that clients might like (“[[commercial reasonableness]]” standard of prudent conduct, general application of laws and so on) put these first. | ||
* '''Interpretation''': Always put definitions last, in a clearly marked out section starting on a new page. But be sparing with [[definition]]s: see below. | * '''Interpretation''': Always put definitions last, in a clearly marked out section starting on a new page. But be sparing with [[definition]]s: see below. | ||
* '''Go easy on the [[boilerplate]]''': Unless you could incur massive financial or criminal liability under the contract (i.e., it is a primary financing, lending or derivative contract) dispense with [[boilerplate]]. Avoid [[Finance contract|finance contract envy]]. Do you need all those reps? [[Entire agreement]]? [[Counterparts]] clause? [[No assignment]]? [[Severability]]? [[Rights cumulative]]? [[Contracts (Rights of Third Parties) Act 1999|Third Party Rights Limitations]]? Do you really need all that? For an [[NDA]]? | * '''Go easy on the [[boilerplate]]''': Unless you could incur massive financial or criminal liability under the contract (i.e., it is a primary financing, lending or derivative contract) dispense with [[boilerplate]]. Avoid [[Finance contract|finance contract envy]]. Do you need all those reps? [[Entire agreement]]? [[Counterparts]] clause? [[No assignment]]? [[Severability]]? [[Rights cumulative]]? [[Contracts (Rights of Third Parties) Act 1999|Third Party Rights Limitations]]? Do you really need all that? For an [[NDA]]? | ||
===Logical structure=== | |||
The logical structure of a legal document is important — like computer code it should be clearly numbered and signposted. The discipline of paying attention to the logical structure helps you to write simply and elegantly. It forces you to organise yourself. it helps a reader navigate, which reduces review time. These are all commercial priorities. Therefore: | |||
*'''Multilevel list''': Number ''every'' sub-paragraph using a coherent multilevel list structure (for how, see “formatting” below). There should be no floating paragraphs without a number. This means you will need to structure your sentences so their logic only branches at the end. Have an elegant and intuitive numbering scheme, using digits, letters and romans, upper case and lower case (but not bullets: there must be a logical sequence to the numbers). Having a paragraph level “4.3.4.1.2” is ''not'' elegant or intuitive. We prefer: | |||
{{subtable| | |||
'''{{font|Helvetica}}1 LEVEL 1</span>''' | |||
1.1 '''Level 2''': Lorem ipsum | |||
:(a) '''Level 3''': Lorem ipsum | |||
::(i) '''Level 4''': Lorem ipsum | |||
:::(A) '''Level 5''': Lorem ipsum | |||
::::(I) '''Level 6''': Lorem ipsum | |||
:::::(1) '''Level 7''': Lorem ipsum}} | |||
*'''Optimise the number of levels''': Unless you are writing a monster document, you should not need to get anywhere near 7 sub-clause levels. If you do, this is a fair sign your logic is over-engineered. Don’t just collapse sub-paragraphs to reduce the number of sub-levels: rewrite the logic of the paragraph so you don’t need so many sub-levels.<ref>See: [[Semantic structure]].</ref> | |||
*'''Indent''': Always use “nested” indents — like modern computer code — as it effortlessly reveals structure, creates white space and allows, er, room for [[Mark-up|manuscript markup]]. | |||
*'''[[Fingerpost|Fingerposts]]''': Include descriptive headings and a brief “fingerpost” for each sub-clause: the clearer the organisational layout is the better. | |||
=== Formatting === | === Formatting === | ||
'''Microsoft Word''': Learn how to use paragraph-formatting, character-formatting, multilevel lists, auto-numbering and style formatting in MS Word. It is hard, somewhat counter-intuitive, but if you learn it, it makes formatting and organising paragraphs so much easier. | '''Microsoft Word''': Learn how to use paragraph-formatting, character-formatting, multilevel lists, auto-numbering and style formatting in MS Word. It is hard, somewhat counter-intuitive, but if you learn it, it makes formatting and organising paragraphs so much easier. | ||