>
>Can anyone provide me successful working examples of the bucket approach
>for email?  I.e. what buckets you created and if user adoption has been
>any problem.  Thanks.
>


A lot of this depends on your business model.  If you have a functional
retention schedule and the work staff performs is directly related to those
functions, it's pretty easy.

First users have to determine "record or non-record"- if non-record, delete
after reading or leave in the in-box for auto deletion.

If record, you need to poll users to find out the TYPES of records they
typically receive/send by e-mail and then map a folder structure to
accommodate the retention periods.  This is generally done be setting
"bands" or "buckets" that may either exceed or shorten actual retention
periods for some items, and match them for others.  

For example, If you have a majority of items that are 3 years, but some 2
year and some 4 year, set the bucket for 3.  Similarly, if there are some 5
year, a ton of 7 year and some 8 year, set it for 5.  Naturally, you need to
determine what risk there may be from retaining things too long or not long
enough, based on what they support and you make a trade-off- is it cheaper
to have people spend less time accurately assigning retention than the
potential risk of improperly retaining things?

In my personal situation, I have a majority of my records CY+2 or CY+>25,
with  a limited number of CY+6.  My buckets are 3Y, 7Y, 25Y, 75Y and the
non-record stuff is held for a maximum of 180 days. 

Is it perfect? Nope... but after discarding the non-records stuff, I'm only
categorizing 7% (on average) of what I receive/send now.  I spent 4 months
checking and charting EVERY message sent received to determine the
appropriate buckets and during that 'study period' the average number of
records was 7.3%... it remains similar to this day.

Larry
[log in to unmask]

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]