Editorial Calendar | Contributors Guidelines


...................................................................................................................................

By Mark Albert, Editor In Chief

For case histories, I am looking for articles that show how a product solved a problem for a user. That's the basic formula. So the problem has to be presented clearly, preferably in measurable terms. The problem could be a bottleneck, a quality issue, unsatisfactory productivity, excessive downtime, an operator or programmer issue (too hard to do, too easy to make mistakes, etc) -- whatever. "Measurable terms" mean figures on how long something takes, specs on tolerances or surface finish or accuracy -- quantities, dimensions, times.

Next the user has to be profiled clearly but succinctly. Is it a mold shop, a job shop, a production plant? What industries does it serve? What kind of products does it make? How many people work there? What kind of machines do they have and what kind of operations do they perform? (Avoid users who have products of their own that are marketed to our readers such as other machine tool builders.) The key individuals need to be identified and it should be clear why they are in a position to know about the problem and feel its consequences.

Next I like to see some indication of why the problem is urgent or serious. Is it causing delivery dates to be missed, quotes to be turned down, profits to be lost?

By this time, readers should be engaged in the story. They can identify with the user and picture the circumstances. They want to know how the problem gets resolved. (Keep in mind that most shop people don't get to see what many other shops look like or how they deal with things. Case histories give them a glimpse into the rest of the machining world and this window helps them size themselves up against other shops. They can see that other shops have problems too and it's reassuring to them to see that help is at hand from a vendor.)

Now we have to find out about the product. What is it, how does it work, how did it solve the problem? Specifically, what features(s) really made the difference? It's very important to relate specific product features with specific user benefits. Details about the technology behind the key features are also important, especially if the technology is new. (Information about technology is the real payoff to readers in a case history and the best justification for them editorially.)

We usually don't need a lot of information about how the user found the new product. The role of a VAR or distributor is usually not important to readers.

Now we need to know what the results of the change or use of the new product are. Facts and figures present the strongest evidence. Again, we're back to measurable terms. I like to see "before and after" comparisons. "From 5 hours to 20 minutes" (when shorter is better), "from 20 minutes to 5 hours" (when longer is better), "from 200 ipm to 1000 ipm," "from 100 parts per shift to 200 parts per shift."

We can let results like this speak for themselves. No need to have the user gushing glory and praise about the product or the vendor. Readers can judge for themselves the value of the product. No sales pitch is necessary (that would hurt credibility and readability anyway).

I don't like to see too many quotes. Quotes take attention away from the product or the problem and focus attention on the person speaking. Quotes are best where the credibility of the speaker as an authority or eye-witness comes through. Quotes can allow a technical issue to be rephrased in down-to-earth language, thereby adding clarity and some color.

Case histories don't need fancy endings or rhetorical flourishes. A tidy summary of the results and the benefits will do. Keep in mind that a case history is more like a newspaper report than a short story even though the narrative structure adds interest and appeal. A neutral, objective journalistic tone works better than a cutesy or "literary" approach. Sometimes a motif lends itself to a nice hook at the beginning of an article and returning to that motif at the end gives the article a satisfying unity and closure but don't force it. For example, a case history about cutting tools that helped a shop make better forging dies for golf club heads might use golf imagery as descriptive language.

The main thing is to show the product in action in the field so readers can see what it can do. Shorter pieces that stick to the point and follow the formula are the most useable to us editors.

Illustrations are important. We use one or two (occasionally more) with each case history. Color images that show the product in action are best. Ideally, the illustration helps the reader visualize the problem and the solution. Remember that our readers are technical people and are drawn to pictures of workpieces and machine tools most of all. They are less interested in what the shop owner or machine operator looks like. Sometimes key people mentioned or quoted in the story can be photographed holding the troublesome workpiece or posed looking at the product in action. (Be sure everyone is wearing appropriate eye protection and safety apparel). Side by side photos of before and after scenes (old workpiece/new workpiece, old tool with excessive wear/new tool with little wear) are welcome.

Be sure to include captions that identify the products in view, name any people, and describe the significance of what is shown.

Final advice: Please call before you start writing. We can help you take the best approach to the article or avoid mistakes that make the case history less attractive for publication.

Articles should be sent as Word For Windows files (as e-mail attachments or on diskette). Illustrations as .JPG or .TIF files (at least 300 dots per inch) are also welcome. Color prints or slides are acceptable as well.