Client defined

I just came across a great definition for "Client".

"A client is a partner, someone who I have an intimate relationship, is in it with me for the long haul, someone with whom I co-invent the future, a person/organization in whose outcome I have a big personal stake, someone with whom I have an emotional bond, someone with whom I can’t work if trust is not paramount, a fellow professional who, like me, wrestles with intractable problems, the source of my reputation (for better or for worse), my No.1 “word of mouth” marketer, someone who grows with me, someone who loses when I lose, someone who wins when I win."

The greatest thing in the definition, is that it is not only descriptive, but also prescriptive. It tells you how to treat your "customers" to convert them into "clients". In português, "client" is translated into "freguês", which I love, because is the same word used for people frequenting a bar. I'm shure that if you ask a bartender, he can tell you the difference easier than an IT Sales rep.

By the way, the definition is quoted from Tom Peters book "REINVENTING WORK: the professional service firm 50". I'll go get it right away.

Sharepoint easy e-mailing Alerts and Reminders

Even when Sharepoint 2007 (MOSS) has a lot of Document Management Capabilities, I've found it lacks of some basic features. One of those missing features, is alerts and reminders. You can define a document's expiration date, but no feature allows you to easily remind the author the date is near, nor aler the author's boss when time arrives.

The top-of-mind solution for such a problem is using workflow. You can dispach a new workflow instance for every doc, then wait until (ExpirationDate - x days) arrives, and then send a mail. But what if you want to add looped reminders after the first one, and then scale-up to the boss, etc. The workflow rapidly grows outside Sharepoint Designer scope and you fall into using WWF for an originally peanut sized feature.

Here at Infocorp, together with Andres Barreiro, we came across a simpler, (IMHO) better solution.

The use case would be like this:
1) On setup time, the policy manager builds the "Revision Plan", creating several recurrent appointments on a Sharepoint Calendar named "Revision Plan". As seen in the picture:
a. First appointment, tells the user to update the document
b. Following ones, remind the user daily
c. Last one, tells the user that the document is past due.
2) After that, authors work with the documents as usual. Based on the meta-data, documents appear on several tracking views, such as "Pending Reviews".
3) (Here's the trick) In background, a daily scheduled service loops trough the revision plan/document library and when needed, sends traditional, all-mail-version-client-compatible mails to authors:
a. Mail body is taken from the appointment's body
b. Mail to: field is filled with the document's author e-mail.

I believe this solution, sill being functionally equivalent to the others, has multiple advantages:
1) Management: All the reminders logic resides on sharepoint lists, very handy for business managers. Changing a reminders period, or editing the message are piece-of-cake tasks :-)
2) Deployment: The single non-sharepoint component is an "x-copy deployable" .exe file (the service) scheduled by Windows scheduler.
3) Extensible: The service's logic could be easily improved in future occasions, using custom columns on the Revision Plan Calendar as parameters. For instance:
a. If document is due without revision, and column "Block If Due" of revision plan is ON, then set "Status" field as "Deprecated" (which makes document disappear from views)
b. After 3rd reminder, if column "Notify User's Boss" is ON, then fetch user's boss name on Active Directory and send a second reminder.
4) K.I.S.S. Principle: The solution is much more simpler than the WWF approach.