I've just moved a client's email services over from my host to Google Apps. I would like to hand over a document providing all they (or their agent) need should I not be available etc.

How are such documents normally structured, and what level of detail should they contain? I know user names and passwords are essential, and instructions on how to manage domains on Google Apps are over the top, but what is a commonly used middle ground?

  • If you're done with the project, it's already too late for good documentation, IMO. You need to document while you're in process, not after the fact. – EEAA Apr 19 '10 at 2:10
  • sounds like a make-work project (hope it's billable!): you could just as easily send them some relevant links to the Google Apps documentation. – gravyface Apr 19 '10 at 2:18

I am not sure how the documents would normally be structured, but in this scenario I would think documenting the following is appropriate...

  • administrative usernames and passwords
  • guidelines for creating new accounts (e.g. naming conventions)
  • changes you made to MX records
  • changes you made to DNS
  • cautionary statements about making changes to DNS if they have the ability
  • links to access their services (e.g. the DNS entries you setup)
  • links to Google's client oriented documentation (pop3/imap/smtp instructions etc...)
  • links to Google's administrative oriented documentation

One to two pages should be sufficient. Include a short summary of what Google Apps is and how it is different than hosting your own email or using your ISP's services.


We tend to hand over build guides - if it contains a systematic description of how to build the system from scratch, it's probably got all the essential details. Add an FAQ or links to Google's howtos, and you should be fine.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.