Where I've worked, the solution is usually...more documentation! Policy and procedure documentation, not documentation documentation. So there's a checklist or something called like "Procedure for asking Agency X for Foo" and you have to fill out a checklist sheet (which details which document to send Agency X, how to notify the client, etc.) and sign and date it to show you've done all of the steps.
Can't you just have a client database that pops up only relevant information to people not servicing the client?
Updating the turnover folder is the last thing anyone wants to do before leaving, but the most important. Part of the exit interview has to include the turnover update. Yes, I know this is not optimum or even practical, in some cases.
The problem with 2 is that the person filing the form wouldn't even think to check the client, because the client has made a unique request.
Mac stickies. I check them every day. There are 42 of them or so on my desktop, but I still check them every day.
It's true that high-turn workplaces have to invest more in process to keep things operational. The more training a person needs (and large volumes of documentation are a dead giveaway that the training bar is high) the more trouble you'll have with turn.
You can enforce process in many different ways. These days many companies use software, and many's the time I've helped build and install workflow engines to handle just this sort of thing.
But you could just as easily fill the need with people (in the form of case manager types of individuals) or with routing patterns (for example all forms of a given type needing to go thru a certain office at the point where some sort of logical branch occurs). Then you at least have fewer people who need to be informed of the SOP.
I think the biggest challenge is convincing higher-ups that the turnover is a problem that might impact quality. Not the sort of thing people want to admit, typically, much less respond to.
4: I am certain I lack your (and tom's and Becks's and w-lfs-n's and any number of other commenters') technical skills, so perhaps what follows is obviously idiotic. But aren't you just trying to automate the office? If someone fills out a form on a computer, they must enter a client name and a form number. If they do that, don't you have enough information to know when to have the client database automatically pop that information?
Don't know if this is applicable but I finally got our IT guys to configure things so scheduled, automated SQL jobs can send email. So, over the weekend data gets sent to X, the notice of the sending goes to a fussytwit manager Y, and a failure to finish any of that would get sent to me so I can write nasties to the first guys mentioned.
Is this only for this one client? Could there be a change to the form, so that the person dealing with the form sees "send to client" or something right there on it?
A low-frills solution is to have the information sent to the client by the party with whom you are filing the form. E.g. the way Amtrak lets you enter a second e-mail address at which to receive reservation confirmations.
Obviously, this depends on having a vendor/government agency whose system is designed to let you do that, though. And may not solve the problem of "How does the employee filing the form find out when the client wants to receive confirmation, since not all clients do?"
Also, does the client need timely notification of the filing of each separate form, or can they get a periodic batch notification? It's easy enough to handle if it's the latter -- when the person whose job it is to manage the client relationship gets to their monthly report/periodic check-in, that person just adds this as one more item to report on.
Would it make sense to have a general policy of Formfiling Employee notifies ClientRelationship Employee whenever they file a form for any client, and then ClientRelationship Employee knows if anything else needs to be done?
At this job and at the last we had to verify requests from clients against a list of specific people trusted to make such requests, up to and including calling them to verify a verbal password and confirm the change before doing anything. Does your work involve something similar? If so, adding a "special notes" field to that database of client contacts would give you a place to put special but client-required steps like that.
Didn't Goedel or Turing prove that this problem is insoluble for any n greater than 1 ("n" being employees)?
An alternative solution would be informing the client "Screw you, you'll know what we tell you."
I think LB's solution combined with something like Becks might work. Generate an e-mail to whomever is your company's go-to-person for this client whenever the form is updated; that person will know whether the client wants to be notified or not, and can take the appropriate action, and update the records saying she's done so.
That way, FormFilingEmployee isn't in charge of deciding whether the client needs to be notified, and ClientRelationship Employee isn't in the position of not knowing the form's been filed, and should either one of them leave, you've got a history of the whether the client wanted notification or not, and a mechanism to make sure that happens.
I usually lurk but this seems so insanely simple I had to speak.
#13, uh, hello.
Like fish in a barrel.
(I love this site, btw. Fading to black once again.)
Yeah, I think these are on the right track. You'd want to make the notification of otheremployee or client part of the filing of the form. But then you also need to make sure that otheremployee knows to include these instructions for the form filing employee when clients make special requests. It's this "being aware of relevant tasks" that can get tricky.
And of course this is just one example. There's the general problem of making sure information gets to the people who need it.
Off to swim.
Now you know.
Templates with built-in macros. When the form is filled out (template), the built-in macros launch a series of events (file to the proper folder, copy e-mail to the proper addressee assuming an e-mail address is a data field within the template). Just make sure the template and macros are fully explained inside your task-oriented documentation.
Or use some kind of *shudder* CRM thingy, so that any action with a particular client could be logged in the same place.
I'm al ittle unclear. Is the form fundamentally connected to the client in some way, or not? That is, is this something like "filing our report on our interactions with the client with the SEC" or "submitting a review of a public agency proposal, and the client might be interested in getting involved but is currently unconnected"?
23: That was my first thought, but then I thought of my experience with CRM, and how unspeakably awful it was to get sorted correctly, and said "hey, I don't have ogged's job! Neat!" and went back to beer-related comments.
Generically, wasn't google supposed to solve all these problems, by organizing all the world's information? For example, I'd really like to find a list of the ingredients in these, but google is not helping.
Having all the world's information at your fingertips is the fucking flying car of the 21st century.
22 - 24
Clarification: It is unclear what application is being used but most database, spreadsheet, or word processing applications have a built-in macro language. A flowchart would like something like this:
1 - Identify all data fields (name, address, phone, department, email, folder, etc.)
2 - Redundancy - A non-printing comment box has all instructions embedded in the form
3 - Write error-traps for each input field
4 - The end of the form would have additional instructions (a reminder to proof-read) plus a "Done" button that would launch action macros.
5- Probable actions: print hard copy, file electronic copy, send email copies.
26: sugar, glucose syrup (wasser), color: caramel (E150), allura red AC, gelatin, agar-agar, citric acid, aroma, coating: bee wax white and yellow, caranauba wax.
Ogged, the answer is completely clear: your company should just hire Apo. He is the organization of information, incarnate.
Here's a shocker for w-lfs-n: Roman names were definite descriptions.
How about tagging that form to automagically cc the client every time it's sent? (This could be the same as 22, no?)
32: And at least among the aristocracy, daughters' names were derivations from their fathers', hence Agrippa sired Agrippina (but then that pattern broke somehow as HER daughter was Agripinnilla).
33: Seconded. If you go on Disability you can STAY unemployed; it's so much simpler (and one might still afford to grow chubby in middle age).
28: you forgot high fructose corn syrup, hydrolysed soy protein and some kind of petroleum distillate. Are you trying to sabotage the U.S. economy?
"aroma" is a user-output
Produced in U.S. markets by 'fragrance'.
And re 35, dammit, I should have clicked the link in 32 first.
Why should 32 be a shocker for me? I'm also not seeing much definite description in there.
Aha, I'm not the only handle-switcher around here.
Cunctator: you remain on your Fabius Maximus?
(That has to've been the worst pun I've thought of in weeks.)
Threadjack! WOE IS ME. No honestly my life is good and I have no place to complain. Except.
The divorcing friend hooked up with someone else. I knew I was in the Friend Zone; I knew she was on the prowl; I knew this was coming. It hurts anyway.
I just had to get that off my chest. And my life, still, is very good.
38: it seemed funny at the time.
Late as ever to all of this. But I think I have two cents' worth here.
skimming the comments has left me unsure as to whether the paper trail is electronic or hard copy, but the principles are in essence the same. One cannot build a process around exceptions. Thats called beaurocracy. So, what you need is a logic to capture exeptions with checkpoints in the standard process.
Now, you have presumably a reasonably standard set of processes around client handling, and a reasonably standard set of processes around agency filing. The join is on "client_name". So you need a central collection of exceptions for "client". The checkpoint is needed in any process which creates documents including "client name" that leave the company but are not adressed to "client". The check point is triggered in 100% of the cases but captures only exceptions (exceptionally, client would like to be informed).
Whether the process is IT supported or good old 100% manual is in principle immaterial. If IT supported you MIGHT think about building workflow logic around the exception handling, but that is expensive icing for what are ummmm well exceptions.
...fades back to semi lurk.
