As a typesetting and data conversion service provider, we sell on page price. No matter how much we spend on R&D and how well we may cope with difficult content or authors, in the end it’s the unit price that matters. If a customer’s procurement department only compares page prices, they will try to replace us with commodity service providers whenever possible. But this will only work well for standardized processes or less complicated manuscripts/authors. As a consequence, the relatively easy, high-volume production will be offshored while the so-called boutique production remains at our shop (because some authors or editors insist that their complicated stuff will be treated appropriately). As a consequence, our average page price even gets higher, because there is less cheap off-the-shelf producton in the mix. As a consequence, the procurement people who only compare page prices seek to quench us out.
What can be done about it? A couple of things.
- Establish a low-cost production line and rigidly define what is included in the price and what is not. The drawback is that the surcharges that you inevitably charge will contribute to the average cost per page, making you still more expensive. But at least the reasons become much more transparent.
- Raise awareness that there are different production categories. The customer might already have different production categories. Convince him that the criterion whether a book is typeset in a standard layout or whether the author used a template is not sufficient.
- Emphasize the role of the intake report. Establish automated tools for checking adherence to templates, image profiles, etc.
- Establish a Web-based frill counter where you document the production editor’s or author’s special requests. For titles that are supposed in a standard workflow, ask a customer’s representative to approve every single deviating requirement.
These measures will assist the customers in improving their own processes and hopefully in moving away from underparameterized per-page pricing expectations. Per-page isn’t going to work in the long run, since more and more publications will be unpaginated. However, moving from page to kilobyte metrics won’t be a solution.
To answer the initial question: a boutique shouldn’t necessarily sell commodities. However, flat, per-page price comparisons might suggest diluting boutique production prices with commodity prices.
Another reason for us as a boutique to keep standardized, high-volume production is: not only do we deliver boutique production, but also boutique workflow consultancy and automation. In order to fully understand high-volume production requirements, we have got to do it ourselves. Therefore, we as a boutique do also strive to sell commodities, against all odds.
BREAKING: In #iOS 6/#MacOS 11, Web access only thru proxy.apple.com. Analyst: Web pages bypassing IAP a threat to revenue model
With all the recent fuss about Apple’s In-App Purchase (IAP) API enforcement, the train toward Web apps will take up more traction.
Apple themselves are constantly improving Mobile Safari: it supports most of the events that iOS native apps do support, it is fast enough, and you can imitate a native app’a user experience quite well already. Plus: the Web has gotten really interoperable. You can get almost the same user experience with any iOS browser as with any Android browser without the need to develop for different hardware/software platforms.
German weekly Die Zeit already draw the consequences and abandoned the idea of native apps for their main content.
So in the view of the hefty app tax of 30%, will players such as Sony or Amazon offer their libraries as a pure Web site?
…in bullshitty publishing industry insiders’ insights.
When I saw this term for the second time today, on page 6 of the flashy “ebook” at zmags (a warm greeting to the surprisingly numerous iPad users who read this blog), I thought it might be worth analyzing whether I was missing something in past years or whether this is a new fad in publishing industry analyst lingo. The latter is true, obviously: