Dysiode

That's what I love about cottonTracks, even if it does lack a bit in the portability standpoint.

Or, even better, have a demo on the home screen, or at least a link to one.

This is one of the most grounded and realistic responses at the moment, and I would like to add a bit from my experiences with anxiety and depression.

While my symptoms weren't as severe when I went to see a psychiatrist he stated future sessions would be less about therapy and more focused on how the medication was working. This may have been poor luck on my part but I instead found a PhD level Psychologist instead because their focus is on perspective and providing you with mental tools you can use over and over again.

That said, I'm not discouraging medication, simply ask your psychiatrist about how much therapy you can expect in addition to the medication, and considered also using a psychologist to help provide mental tools.

There are some interesting hurdles, and you've done a great job of thinking of a few of them! I can see three likely async solutions: SMS style message based (explicitly not real time), real-time message based, or real-time chat.

SMS Style Messaging: In my customer-facing experience with the concept I don't think SMS is suited to the challenge. Instead a full fledged chat application would need to be used. As far as queuing goes, related to this and my experience with Simple most of my interactions a) aren't real-time and that expectation is set when I create a message, and b) if they go on for a period of time they're handled by different CSRs. I've never had a poor experience because of that.

> With a voice call, the representative is on the line with you until your problem is resolved.

Additionally, related to this, there are a lot of times where that's not the case, or there's research to be done and if I were allowed I could do that research and come back with a response. That's discouraged/forbidden in call centers because there's the assumption you won't perform without pressure but that's almost certainly a staffing issue (or if there are too many basic/uninteresting research requests then it may be a systemic problem).

Real-Time Messaging: If we're looking for a more real-time message based solution (i.e. not chat), a single CSR could handle a few requests, but if they get a particularly detailed one there could be an expiration that hands it off to another rep, but that could get messy fast, even with a "So-and-So is busy at the moment, my name is..." (though with more elegant verbage).

Real-Time Chat: As I do everything in my power to avoid calling people, I will use chat if available as an alternative. Now, I can't say I've asked every person I've spoken to, but I know a couple of cases where I can confirm I was their sole interaction. It took a bit longer, but I was doing other stuff while I waited and I had the expectation when I started the interaction.

tl;dr Set expectations of delayed responses to messaging based support, don't bother with real-time messaging as it doesn't make logistic sense, and treat all real-time support the same (one active interaction).

That's absolutely valid, CR exists because customers don't know what to do next. That said, there's a lot that could be done to mitigate that.

- High phone support visibility on how-to pages: Don't link to chat if it's not going to an ideal experience - Focus on customer facing how-to resources: I'm confident every minute spent making the thorny aspects of phones (e.g. moving photos from internal storage) rock-solid is worth no less than an hour of CSR time. - Proactively making recommendations on more ideal support scenarios if applicable: "Hey, before we get started, this part can be tricky and I'd love to walk you through it, it'll only take a few minutes and I can schedule a time to call you if you're busy right now. <details of next steps>." - Perhaps most importantly (I just noticed from your interaction) CSR A should handle (and be given the freedom to handle) the problem from start to finish OR it should be made -very- easy for CSR B to pick up where it was left off (either a great CRM or an honest "I've got a family to go home to, I'm going to hand you off to So-and-So or I'll be back and available at"). That said, Simple lacks consistent CSR interaction but I haven't encountered a problem with the hand-off, most of the time I never notice.

When I was a CSR 99% of the time the customer wasn't my enemy, it was my coworkers (or my CRM).

That said, I don't believe SMS literally is a reasonable form of support and should never be marketed that way, but chat, even in-app chat could substitute. Additionally, providing these methods gives people a chance to ask questions and get resolutions that may be nagging them but not enough to call someone, it also opens up lines of communication to people like myself who get anxious thinking about calling people.

I'm not sure how this is necessarily much different than phone communication with the notable caveat that text is quicker to parse. It's already inadvisable to give that information over the phone as a landline can be tapped and there's plenty of proof of concepts of tapping wireless networks.

At least with an app you have the option of adding in security layers. SSL for one, Simple uses a PIN on their app, Art.com will process a transaction in chat but direct you to their website to submit payment information, and on top of all this you have the added benefit of easily documented interaction. -You- can reference your own interaction without the near impossibility of having a call recording audited (as a call center CSR and supervisor I've seen this happen no more than six times).

In fact, in one interaction with Art.com I sent an email to an agent with photos of some damage to the piece they shipped me in my initial email which resulted in a resolution in the response.

Another case with GIGABYTE I was able to send photographic description of my issue due to a consistent (likely language barrier related) misunderstanding about what was meant by "a missing pin." which immediately clarified the conversation and we were able to move forward.

tl;dr the variety of "offline" security measures available and the convenience gained with "offline" support makes that minefield significantly less dangerous in my experience, especially considering the dangers already present in phone based support.

I can see there being a happy medium here as no all support requests are task oriented. Either a) asynchronous support for support inquiries like "When will product x be in stock?" or "What does policy y mean to me?" where as "How do I setup email on my phone?" could be handle synchronously. or b) begin asynchronously and move to synchronous communication as needed.

At the very least both options should be offered. I almost exclusively use text-based communication unless it's a time-restricted request. This works well for Simple (the bank) where I tend to have a lot of financial questions that I don't need answered -right now- so I shoot off a quick message and follow up if needed; however I've had a couple of situations that required immediate answers and response and those times I absolutely picked up the phone.

Having worked in tech support for two major telecomm companies though, I'm convinced it's most commonly a problem of formatting. The discrepancy between instruction and reality is what throws non-technical people off. Given accurate instructions your grandpa could figure it out at least 75% of the time. One of the companies placed extreme emphasis on their resources with the reasoning "They'll figure it out." and according to them and their metrics they seemed to think most people did figure it out by braille if you will.

Just my two (or more) cents.

A touch interface, for one. Emulates are find and all but I find their inaccuracy frustrating more often than not. Further, it's not just a 20 year old game on an emulator. Somebody has to port it, make graphics (for what they are worth), probably localize it. Sure it's not necessarily as hard as making a game from scratch (though that could be debated), but that doesn't mean the costs aren't similar.

I'm largely a fan of the idea I've felt the burn of the "I paid full price for this because I appreciate your work but now it's 33% off?" moment (Borderlands anyone?). I want to see that abolished. Because I've seen a lot of negative feedback of the argument, I want to offer an addition to it.

As an example, I had my eye on Kentucky Route Zero since I saw it in IGF and I fit the example user "It'll go on sale. I'll wait" But after a year it only went on sale for 50% (crazy, I know) and that happened a couple times. At that point, I knew it wasn't going to go to 66% or 75% any time soon so I picked it up. I can see a happy medium with sales where you make it clear that you won't go on sale for a certain period of time and/or for a specific discount. You don't necessarily have to verbalize that either. I don't follow any KRZ news but it was clear that that price point was not going to change quickly. This way you still get the press about sales (I saw a lot of KRZ at 33% and 50%) without having to screw fans over.

I'm sure there are a few ways of strategizing it that would require some experimentation (e.g. a bit before a steam sale, have another 10% type discount like might be seen on launch week but make it clear that it's not going to go below that). There are also more mediums for sales with the Humble Store now you see a lot of games with shallower discounts.

I will say I don't think this model works as a long term plan however. I like the idea of starting low for pre-orders and then increasing the price over time, but I don't think it would work as expected over a two week period. With Minecraft there was the expectation of more content over a period of a year or so between increases. It may still be viable but that may be a case for early access. Make it clear there that the price will increase when it's finished.

I hate seeing what appears like developers feel like they have to sell out on their baby, and I hope something like this can work.

I felt the same about the thumbnails. Then I checked out the new articles and could easily pick out the spam (Indian Party Wear Sarees in this case). I don't think it's so useful for the top articles since most are primarily textual but it brings out an interesting use case for unfiltered content.

I'm wholly relieved that someone else thinks this way too ( still aware of the fact that most thoughts aren't unique). I never came to the conclusion of metamorphosis, however.

Just felt a need to express my experience of camaraderie on the subject.

One could argue that applies to sci-fi as a whole, but some how Vingie's vision of omnipresent dust motes seems more likely (certainly given several hundreds years of cyclical progress, as in the story) than teleporters or even flying cars. Certainly the conditions in the novel were extremely conducive to that type of a network but such a ubiquitous, space filling network could be useful in plenty of other situations (rescue operations or something as simple as adding a puff of motes to a high traffic area to bolster a network for example). Is it likely? Probably not. Certainly not without wireless power, but it's probably more likely than flying cars as our primary mode of transportation.

For a more near future example Vinge presents the network in Rainbows End, especially given the work that's been done with Wifi meshes. Granted, I haven't heard any news about the idea lately, but as I recall, Google has one in Mountain View delivering free wifi to everyone in the area.

See also: Vinge's Rainbows End for a near future example of ubiquitous networking (amongst other likely visions).