2

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?

Improve this question
2
  • 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, 2010 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, 2010 at 2:18

2 Answers 2

Reset to default
2

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.

Improve this answer
2

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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .