I've found it useful to distinguish between the times I'm asking for something, and the times I'm documenting something. When asking a question, lead with the

I've found it useful to distinguish between the times I'm asking for something, and the times I'm documenting something. When asking a question, lead with the question, and put only the bits you need to clarify your question underneath. For these communications, the shorter you can make it, the better. When writing documentation, you're writing for the future, and should aim for completeness rather than full comprehension immediately -- you want something people can look back at later when they're not clear on something, rather than something that your reader will read in one sitting and remember flawlessly. Your reader isn't going to be able to retain that much stuff. If you absolutely need your reader to understand some points, I recommend keeping the points as short as possible, and also to your point, asking a question that requires them to have understood what you wrote (e.g. "people who signed up before this date will be grandfathered in, so may see different rates than new customers. Are you aware of any marketing material which might give conflicting information? " -- the answer is probably "no", but in the course of answering that question, they had to understand what you were saying, and as a bonus if the answer is "yes" you've avoided a problem before it happened).