[Excellent news: The Loop reports Apple will not only allow developers to respond to reviews, they’re also rolling out an API that brings in-app rating and review to every user’s fingertips while preventing developer abuse. It’s not quite what we asked for over five years ago as tech support issues – which can start off a bit hostile – will still face the public before developers have a chance to respond and they’ll remain visible, coloring an application’s story without any accountability, unless users remember to remove them. That’s OK. This is a great and much-needed move in a direction that helps users, developers, and Apple. Win-win-win!Thank you for finally taking this part of application development and deployment on the App Store seriously, Apple!]
We’ve been connecting with new users through the Mac App Store since its opening last January. It’s an exciting (and challenging) channel for us with a lot of potential. Lately, we’ve been wondering how to turn it into a hub for positive, lasting relationships between users, their developers, and Apple. Here are 4 changes Apple could start working on today to make the Mac App Store a better experience both before and after purchasing your apps.
1. Foster Healthy Dialogue Between Users and Their Developers
Like effective user interface design, which clearly communicates its purpose without forcing the user to open a manual, effective customer service begins long before the customer actually asks for help. A simple Frequently Asked Questions web page, for example, can answer a question in a few minutes without the hassle of an email or a phone call. This kind of resource also works great during evenings and weekends, when support resources are tight or non-existent.
Getting to a developer’s support resources from The Mac App Store can be challenging for some users. It gives users a link to their developers support webpages but there are two issues – the links are positioned on the far right side of the page, near the top, and they’re in very low-contrast light grey on a light grey background. To see what I mean, click on the following image and try to find the support link:
CheckBook at the Mac App Store – Can you see the support link?
How long did it take you? The support link isn’t part of the dominant top to bottom flow of content on the left side of the page, nor is it inside the two information boxes that stand out clearly along the right side of the page. The developer website and support links are in a “blind spot”, outside where the user’s eyes are most likely to fall and, because of the light grey on light grey, they’re not eye-catching even if the user looks in that direction. Apple can easily remedy this by moving both links to the “Information” box on the right side of the page and displaying them in the same high-contrast black on light grey background.
But say a user has exhausted their developer’s support resources. What’s next? Most send an email or call their developer directly – but by that point some users are very frustrated because they either don’t know how to contact the developer or because they think the developer can’t be contacted directly. Their issues are very important and they don’t know where to turn. That’s when they head straight to the bottom of the product page to write a negative review. It’s a tech support cry for help but Mac App Store reviews are not the proper forum for tech support. That’s because developers have no way to respond to a review. While the user writes out their tech support issue Apple does take a half-step to make sure the user stays on point, asking “If you need support, please visit …” with a link to the developer’s support webpage at the far right of the review box. This doesn’t go far enough. The user is frustrated. They’re not likely to see questions and links in small print off to the right side of the page. They’re ready to talk NOW. How can we help them?
We can’t today, but with a few changes we can turn this into an opportunity to support the user. The question, “If you need support, please visit …” could be asked in a modal format, giving the user a moment to pause. The user might realize this is a black and white situation – if you need support, visit the developer, if you want to write a review, proceed. This won’t catch every tech support issue, though, because the user can still proceed and write what they want. That’s their right and it should not be taken away (within Apple’s discretion). But that leads to two other suggestions.
Knowing the user may press on and write up a tech support issue in a negative review, why not quarantine negative reviews (reviews of less than 3 stars) for, say, 24 hours before letting them go live on the Mac App Store? Explain to the user their negative review will be quarantined if they proceed. Halfway through the quarantine period send them an email explaining the review will go live if they do nothing but it can still be rescinded. That way, if the review is actually a tech support issue, the user has time to find an answer and they might even pull the review before it goes live. If not, then the quarantine runs its course and the review goes live. So what if the review is a tech support issue and the user doesn’t find an answer? Can we still help the user?
Today, the Mac App Store does not provide developers with contact information for each sale. It also does not provide developers with a means to respond to reviewers. What developers need, at the very least, is a reliable communication channel with every reviewer, positive or negative. It’s fine if Apple feels contact information should be kept private, but what about letting developers communicate with their reviewers through anonymous email, like Craigslist, or through a private messaging system built into the Mac App Store itself? If Apple is concerned about spam or other abusive behavior from developers a single complaint could easily be tracked to the offending message. For things like harsh wording, which are subjective, three strikes and you lose your communication privileges, temporarily or even permanently. But be flexible, Apple. Get real people talking it out on the phone, if necessary, before you take serious action. A blanket policy with a cold form email backing it up and no appeals process? Poor form. You can go right ahead with a zero-tolerance policy for spam, though.
2. Let Users Try Their Apps Before They Purchase
“Try before you buy” is a gospel often heard at the corner of “I don’t know how it works” Street and “It costs a lot” Avenue. When a product’s price is outside our comfort zone and we’re not sure it can do what it says on the tin, we usually have a hard time signing on the bottom line. Take cars. They cost so much some of us have to take out a 6-year loan and scrape the cash together month-to-month. And, to most people, what’s under the hood of a car is more or less magic. The specs on the sticker are like reading a foreign language upside down. All you know is you put in gas, change the oil every so often (right?) and it just works. So you don’t buy a car without a test drive – which seals the deal (or blows it). Works for cars…and also works for software. Users don’t know what they’re going to get when they purchase an app and they’re not comfortable paying more than, say, $5 to find out. When they take a leap of faith based on flashy screenshots or a great app description, then get burned, most users are very likely to demand a refund and think poorly of the app and its developer. Users need to try before they buy.
And it turns out try before you buy is a relatively easy thing to implement on Apple’s end. Just encrypt a trial mode flag in the receipt file for each app. Developers could check for the flag to find out whether to run in trial mode. And to make this easy on the user, keep them in the loop with a consistent user interface: each time an app is launched, Apple could display a Mac App Store dialog to tell the user they’re in trial mode, with buttons to continue, purchase or uninstall. A finer point: Many users are foggy on whether the data they enter in a trial app will still be around when they purchase a real license. The Mac App Store could reassure them up front at the time of purchase.
(Apple seems to prefer developers adopt in-app purchase to get trial mode functionality – but that’s just not the best strategy with Lodsys, the patent-holder for Apple’s in-app purchase technology, throwing lawsuits at developers – even Mac app developers – for using it without their official blessing.)
3. Let Developers Initiate Returns on Behalf of Their Users
When users decide to throw in the towel on a product they need a clear path to receive a refund. Problem is, there’s no “Refund” button in the Mac App Store application, just a link to the Mac App Store support webpage at apple.com. Guess what? There’s no “Refund” button on that page, either. And then? Well, there’s no “Refund” button on any of the pages you can reach directly from the main support page. It’s so confusing and frustrating that users often turn to their developers for a refund – but the developer can’t help because only Apple can approve and initiate a return. Apple could take the lead here again and empower developers to initiate refunds for their users. If the developer is OK with losing the sale, why not? The user’s needs are met sooner, with less hassle and more respect for their time, and Apple gets to keep their 30% anyway, even on refunds.
4. Give Developers a Human Point of Contact at Apple
The Mac App Store costs developers a cool 30% of gross revenue. Put that in perspective: eSellerate and FastSpring charge just 8.9% or less, and among the perks for paying less developers get a live human account manager to speak with during regular business hours. And it’s not even that expensive. In the 8 years we’ve been with eSellerate we’ve gotten on the phone with our account manager 5 or 6 times – and 2 of those times they called us to say hi and straight talk about our concerns or suggestions. Total time on the phone: roughly 3 hours. Over 8 years. Apple has an additional 21.1% (or more) in revenue to work with here and right now all we get is a complicated email form. When we have a question about the Mac App Store we need a human point of contact to either answer our question or give us a gentle push toward the right resources.
Apple could even take the lead here and give their developers a 24/7 emergency contact. Let me tell you, when you have a customer-facing situation on the Mac App Store on a Friday night it’s a looooooong 60 hours until Monday morning. We recently had this get in the way of properly caring for our users (see http://www.splasmata.com/?p=1486 and http://www.splasmata.com/?p=1571 for technical details). Initial reports came in over a weekend. We watched negative reviews pile up for our products at the Mac App Store for two days before we could get anyone’s attention at Apple through their email form. That’s poor service for our users and a lot of angst on our end that wouldn’t happen if we had an emergency contact at Apple. This is a golden leadership opportunity for Apple -provide an example of good customer service to developers and those same developers will follow Apple’s lead, creating healthy, sustainable customer service relationships with their users.
What Now?
Apple can start today with subtle tweaks in the Mac App Store’s layout, gradually improving the review process using our other ideas as a starting point to open a healthy communication channel between users and their developers. Likewise, Apple can take the relatively painless step of adding a trial mode flag to the Mac App Store receipt file today, gradually improving the user interface side so trial mode is consistent and easy to understand. Letting developers get the ball rolling on refunds instead of bouncing users between webpages and/or between the developer and Apple would tell the user their time is valuable – and where we come from that’s just good manners. Finally, Apple has a great opportunity to open up communication between the Mac App Store staff and developers, making it easier to serve the user and laying the foundation for professional relationships built to last.
Thanks for reading – please comment on this one if you get a chance!