NOTE: I haven't read the lead story so hopefully I'm not being redundant ...

The biggest barrier, IMO, isn't in applying retention to email, it's more
about getting email into a system in the first place.  That is where more
automation is critical (and often the hardest to achieve because people as
so darned emotional about email).

As it goes, you can provide a repository for filing of content, including
email, but you generally have to rely on end users to move email to the
system.  People are always problematic.  And with most ERM/ECM repositories,
there is a profiling step that typically sits as a large brick wall between
intent of the system and actual use of the system as intended.  What often
happens is 1) people just find some other place to stash important email,
such as their gmail account, and/or 2) they apply the metadata that shows up
first in the picklists in order to speed up the process (but which
dramatically affects overall adoption and success of the solution ... more
on that in a minute).

If you are going to attempt to move email to a content repository by manual
means, you need at least the following for any kind of consistency:

1. Integration into your mail client.  Don't make people leave their email
environment to file email.
2. As flat a file structure as possible (read: big buckets on steriods)
3. The absolute least amount of manual profiling as possible.  Use every
default you possibly can and apply metadata through folder structure
inheritence.
4. Very clear guidance on which emails consitute a record and which don't
(so you don't end up simply moving the storage of junk from one server to
another)
5. A corresponding policy for email retention on email servers.  Regular
purge policies, if designed and implemented well, actually encourage regular
filing of important email (note that I said encourage, not guarantee ...)
6. Regular monitoring, training, retraining and enforcement.

Another barrier to getting email filed into ERM/ECM repositories, from my
experience, is poor search functionality/training.  If people are asked to
put their precious email into a repository you had better be sure they can
find it quickly; but honestly many implementations neglect to account for
this need.  The majority of effort is spent configuring capture, then second
is lifecycle management, then last is user interaction post-capture.  I
contend that approach is entirely backward.

All of that said, I'd recommend you look into the possibility of removing
end users altogether.  Find a way to manage their email without involving
them AT ALL.  Although people will claim that all of their email is
life-shattering important, keep in mind that in reality a vast majority of
email is transitory in nature and need not be retained for any extended
period of time (depending, of course, on your industry, jurisdiction, role
of the user, etc.).

And for as much as Steve W. hates paper, I hate email.

Julie



-- 
Julie J. Colgan, CRM

[log in to unmask]
http://twitter.com/juliecolgan
http://www.linkedin.com/in/juliejcolgan

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance
To unsubscribe from this list, click the below link. If not already present, place UNSUBSCRIBE RECMGMT-L or UNSUB RECMGMT-L in the body of the message.
mailto:[log in to unmask]