2014-01-08

How One Cheap App Could Totally Change Our Newsroom

When it comes to automation, every business should sweat the small stuff.



I got a lot of funny looks around the office when I told people I was building this little web app to generate invoices. After all, invoicing is our freelancers' problem, not mine as the editor of this site. You see, the vast majority of stories you see published on the Fast Company are written by out-of-house writers who we've contracted to work for us--at the end of the month, they bill us.

And every month, someone manages to screw up the invoice workflow mandated by accounting. As I wrote in my first post about this topic, this error-prone process is like a lot of "training" issues that crop up in companies everywhere:

Each time you find a writer who has done great work in the past, there's an adjustment process to the tone and content of our particular publication. In a regular job, you'd call it the training period. These writers need to get to know how we do things, how we expect work to be rendered, how we edit, revise and fact-check, and how we incentivize and compensate them."

Even veteran FC writers manage to mess up the invoice process once in a while, resulting in a tiny workflow trainwreck. If a writer leaves out a piece of information on an invoice or incorrectly formats it, a flurry of emails appears between me, our managing editor, and the writer--who usually ends up re-invoicing the correct way after we catch the snafu. With 10-20 writers working for each of the Fast Company sites in a given month, this can be frustrating, especially as we grow and hire more writers.

Is invoicing the biggest problem our organization faces? Probably not. But it's all these shamefully unambitious little problems--the time-sucks--that your company can't afford to sleep on. Instead, I think we should be eliminating the inefficient friction points one by one so our company can operate more smoothly. As it turns out, focusing on the little problems can often reveal bigger ones, as was the case with the invoice app.

How A Little Invoice App Snowballed Into Something Much Bigger

For the next version of the invoice app, the logical thing was to automate more of the invoice process. Instead of having each writer keep track of their stories, and the price I quoted them for each one, I figured we could reduce errors and pay people more accurately if the app kept track for us. Here's how the new app--which we deployed at an old domain name I had, Readliner.com--takes this automation to the next level.

First, Readliner sucks in each story that my site publishes using our RSS feed, along with its metadata. It presents me the day's stories in a neat list. There, I can assign a price to each story. Normally, I would verbally quote the writer a price and let them keep track of it. But we produce too many stories for me to go over each writer's line items one by one checking their prices against my memory, so this could be a major source of slippage, as they call it in the capital markets. (Slippage is the difference between what you think you're paying and the actual cost.) I'm not saying our writers are out to gouge us, but media companies don't operate on the beefiest of margins, so even a small amount of slippage here matters.

Now, with Readliner, here's the interface editors see. For privacy's sake, I've blurred out the prices.

This is where I (the editor) can go in and set prices for each story. You'll notice that Readliner also tells me the average price I pay this writer for a story, as a benchmark. The flow is simple enough: I login and price stories about once a week, then go about my business.

Each writer can also login into Readliner (with his or her Twitter account) to see a list of stories from the last 30 days, complete with the prices I'm paying them for each one. Thus, writers are happy because they get a neat, automated, and accurate way to track their earnings.

At the end of the month, when it's time to invoice us, they click the only button on the screen: Generate Invoice. Out comes a properly formatted, correctly priced, comprehensive list of their stories in a nice PDF invoice, which they can email directly to our accounting department. Because the system is automated, these invoices can be submitted without my approval, removing one more bottleneck for me to hire more writers and scale up my site.

Here's the interface the writers see:

Why The Invoice App Matters: Accuracy

Slippage is one potential issue, but a bigger one is how we price stories. Normally, I quote the writer a price on a story at the time they pitch it--which is also the point where I have the least information about how this story will turn out. The price I quote for a given story is based on a few factors: anticipated traffic, the amount of reporting, and the amount of research are three major heuristics. At the time of the pitch, I know very little about each of these--it's a nascent story idea, which is tough to assign value to.

By offloading the pricing on myself via Readliner, I'm able to price each story later in the process--after it's done and published and appearing in our RSS feed. This is a much better juncture to evaluate how much I want to pay the writer for the piece. How well did it turn out? How hard did they work on it? How much trouble was the editing process? These are all factors that deserve consideration when pricing, and didn't before Readliner.

I haven't been able to quantify whether (on the whole) this new workflow will cause me to spend more on content or less. But the major win here for me as an editor is that it has improved our accuracy--both in the way I price stories and the way writers bill for them. That's no small feat for a silly little PHP app that I wireframed on a Post-it note and then outsourced to a friend in Nepal for a total of $1,500.

That's why small problems are worth solving! They are often symptoms of larger issues, which may also be solvable with software.

Let me know if you have questions about this app or our workflow @chrisdannen on Twitter.

[Image: Flickr user Camilo Rueda López]