- January 2020
- February 2016
- July 2015
- May 2015
- February 2014
- December 2013
- May 2012
- May 2011
- November 2010
- August 2010
- March 2009
- December 2008
- November 2008
- October 2008
- September 2008
- August 2008
- July 2008
- April 2008
- March 2008
- February 2008
- January 2008
- September 2007
- July 2007
- June 2007
- May 2007
- April 2007
- March 2007
- February 2007
- January 2007
- December 2006
- November 2006
- October 2006
- September 2006
- August 2006
- July 2006
- June 2006
I guess that it’s called experience when you’ve seen this one before. As the stock market is falling, venture capital is freezing up and we’re looking for a new president – it’s obviously reminiscent of 2008. It seems sort of obvious that oil will be expensive in the future, unemployment will rise and new great startups will form. Nothing’s ever for sure, but cycles do seem to repeat, at least the broad strokes.
There are always new factors. This time around there is much more at stake for me personally. Things seem more normal, rather than the Black Swan of 2008 and the media seems to be much more alarmist, than genuinely concerned.
I wonder what will seem like the obvious best move in 2-3 years.
I’m writing a series of posts about messaging for businesses. Even with a simple sentence like that, there are a lot of definitions that need to be fleshed out, but generally I’m thinking about businesses using channels like Facebook Messenger, Snapchat, SMS, What’s App, and the like, for two way communications (not advertising, not broadcast).
Although there are limitless examples of advertising and broadcast channels, there is a really manageable number of true communication channels. It’s possible to look for patterns in how they arrive and evolve with the goal of helping us think about where this newest channel – messaging – might be headed.
Let’s start by taking a look at good old direct mail. The channel started with people writing letters to each other. It was person to person correspondence. That might have lasted a long time, but at some point business started communicating with people using the mail – invoices, reminders and confirmation of orders became normal.
Let’s think about other channels like the telephone, email, IM and text messaging in a similar manner. These channels start as a way for people to communicate with each other. Over time, businesses realize that they need/want to talk to people on this new channel. Email definitely worked that way, right? I wasn’t around for the invention of the telephone, but I bet it was similar. With each channel there was probably a little bit of friction – I’m sure there were managers resistant to calling people instead of telegraphing them. There were definitely managers resistant to email the non-profits supporters and cutting back on direct mail (they still exist).
Enough history – why am I writing about this? I believe the newest communication channel can be labeled Messaging and it’s going to fundamentally different from the channels that came before it. I’m thinking through the implications and looking to better understand the different brands of messaging, and the way that different companies approach different brands.
Messaging is in a really interesting place. Right now it’s almost exclusively for P2P communications, but it’s quite clear that will be changing soon. Facebook Messenger will be opening up for business and Application 2 Peer messaging is expected to grow while traditional Peer 2 Peer messaging is shrinking. It’s a really exciting time to watch messaging make this transition, and to try to understand where it’s heading.
Messaging will be more interesting than the channels that came before it (email, phone, mail, fax). Where previous channels were a protocol, messaging is, for the most part, branded. SMS might be the only messaging protocol. Every phone call is the same – there is no difference between service from AT&T, MCI and Sprint. With messaging there will be big difference between Line, Facebook, Whats App and the like.
Why should you listen to me? I’m hoping the content speaks for itself, but before the content arrives it’s helpful to know that I’ve been working in Messaging for over 7 years. I’ve had thousands of conversations with companies, government agencies, non-profits and public services, discussing how they can approach Messaging as a channel to communicate with populations. I’ve worked on some of the largest and most visible messaging campaigns ever and I spend every weekday thinking about this stuff.
That’s easy enough, right? There has been a few articles recently focusing on SMS. That’s exciting because I’ve been working with an SMS platform for 7 years and happy to be hearing more buzz about the channel. I read an article, What SMS is good for http://whoo.ps/2015/05/27/what-sms-is-good-for and here is my take.
For many channels- apps, email and web- businesses need to learn the tricks and secrets of the channel. SMS is a little different. Text messaging is the most human communication channel, so if you use SMS in your personal life, you have a really good start to using SMS in your business life.
The shortest and most direct answer to the question, “How can a company use text messaging?” is. If communications will help achieve the outcome, then SMS can usually help achieve that outcome. SMS is the best channel to reach the most people period. It’s really that simple, but of course more explanation helps.
From a business communication perspective, SMS is similar to email. In fact, conceptually, they are exactly the same. A company is going to build a list of people and then communicate with those people. These communications can be marketing/broadcast type communications or more specific, targeted and transactional communications. SMS, just like email, can do both.
There are some key differences with SMS, I’d call them advantages.
SMS vs email: starting from a high level, the first advantage is that it’s 2015 and text messaging is a more ubiquitous form of communication in the world, and definitely in the U.S. More people check there text more often than they check any other channel. Certain demographics ‘never’ check their email (< 20 years old, <$30k). Basically, anyone that doesn’t have a desk job, fairly rarely uses email, but they do text. 6% of 19 year olds check their email daily, that’s about the same number that check their telegraph messages daily. That same 19 year old sends or receives 181 texts per day. This is all pew data.
SMS vs email: going down a level… Text messaging is the way that most people talk to their mom, kids, significant other or best friend. So text is most people’s most important channel. The open rate for texts is 99% (as per the ctia) and the average text is opened in 90 seconds. Compare this to your email list open rates- if your doing a great job you see a 20-25% open rate and that takes 2 days. SMS is a much more direct channel- your message is going to be seen, and it will be seen quickly.
SMS vs email: now PMA more conceptual level… Email is built for blasts, SMS is build for conversations. Transactional messages are straightforward and SMS probably works a little better than email- “your uber is arriving now”. But the real power of mobile is that it’s built to be conversational, and users will respond to messages when asked- that behavior is built in. Think about, “your uber is arriving at the house. Should we come to the front or side door?” or “your uber is arriving, do you need to put anything in the trunk? Reply yes or no”
SMS vs email: the final big difference is that SMS can be used for acquisition. Email has nothing like that. Unless someone is already filling out your form, they will be more likely to text in their email address rather than give it to you online. So if you tweet out, ‘click here to sign up’, you will get less acquisition that if you tweet ‘text signup to 12345 to signup’. This might sound counterintuitive (I promise it’s true), but it should be glaringly obvious from traditional media. Is anyone out there opening up their laptop to go to your site instead of continuing to watch the cavs beat the clippers? Worse yet is anyone writing down your website, going home and signing up for your on-site promotions? But they absolutely will text in, they’re already texting Rhee friends right now.
When you combine the user behavior with the conversation advantage, that is where the real acquisition happens. “Thanks for texting in to join NBA mobile. First reply with your name and email address.” That message is sticky, valuable and converts better than any webform ever. The average response rate is greater than 80% and depending the population being targeted, can be as high as 95%. So when we talk about mobile acquisition, it’s not just a phone number, it’s an actual profile- name address and phone.
** an important key to making all of this work is that the SMS platform needs to be good at processing those income texts and parsing data. Most platforms focus on blasting out only (that’s what email does), but completely skip the more important part- processing outgoing messages.
Back to the original question, “what is SMS good for”. The first answer is acquisition as noted above. If marketing will include an SMS call to action, next the the url, the company will generally see a 3-5x increase in response to thee dis they’re already doing.
The bigger and realer value is that as you build the list of subscribers, the people that allow you to communicate with them over SMS will take more action than the people you cannot text. Obviously, there is some selection bias (I’m not going to let you text me if I’m not really interested). Assuming demand actually exists, the people on the mobile list will convert much better because they are actually seeing the messages (99% open) and they are seeing the message quickly (90 seconds). Back to the basics- if people actually see the message, they are more likely to do what you want them to do.
The most exciting part is that when someone receives your text, they are not locked in to a platform or network. The action can be anything- not just a like or retweet. Obviously response can be an action, but so can a click or phone call. Texts can amplify the results from a web or email campaign, and SMS works tremendously well at driving real world action like reminding people to vote, quit smoking or reorder a product. We have a client that’s helps people start the process to donate bone marrow by texting.
The most important factor to make all of this work well is for the company to know what actions they want to drive, and for that to be valuable for the user. Uber knows that if the text you, you’ll get to the car a little faster (action they want) and it’s a better user experience (value for user). Besides focus from the company, the second most important thing is relevancy. Because people are actually going to read the messages, they can’t be bullshit. Most people ignore there emails, so send as many as you want- not true for texts. That’s exactly the same as how you text in your personal life, you message friends with relevant information- not product name changes and new login processes. Just like real life… There are no tricks to SMS.
A few weeks back I bought a theme from wrapbootstrap in order to play around a bit with a new design. This kicked off a fairly and confusing process to get it set up in my Rails 4 app. I couldn’t find any good answers out there, although I found a few people asking similar questions.
I bought the theme called Treble. http://wrapbootstrap.com/preview/WB089478D I don’t know if the process would be different from every theme, but I imagine it might be.
I was getting crazy errors and tried to require different pages in the manifest file (application.js for example). After all that, the simple solution was that the folders needed to live in the vendor/assets directory. Adding them there, stopped the errors, and the page loaded – although this didn’t fix everything. I could get the page to load, and the JS seemed to be working, but the images weren’t loading.
One of the problems that a friend found was that somehow, bootstrap was being called twice. I couldn’t get a full explanation, but the fix is to comment out line 19 which reads <link rel=”stylesheet” href=”assets/style/bootstrap.css” type=”text/css”>. I’m guessing there were some files left over from the install in app/assets and those were getting compiled along with the files in vendor/assets and this was causing issues.
I still had a few more problems which were solved by copying all the folders into the /public folder. Rails seems to pull the bootstrap.css file from the vendor folder and the images from the public folder. So when you need to edit the CSS, do it in the vendor files and when you’re changing the images, do that in the public folder.
Hope this helps at least someone out there.
I took the One Month Rails tutorial and I’m continuing to build out the site. I wanted to add a credit card charge for a SaaS model business and I’d heard great things about Stripe, so I used them. The One Month Rails tutorial basically builds a Pinterest clone and uses Devise for a User model and authentication. Here is an example from the OMR creator. http://omr-pinteresting.com/
Stripe has great documentation and there are tutorials out there, but nothing was perfect for Devise + Stripe, and I’m also working with Rails 4 and Ruby 2, to make things a little more interested.
I started by building a single credit card charge setup from the Stripe tutorial. https://stripe.com/docs/checkout/guides/rails This works well and is fairly straightforward. The one tricky piece for me was pushing through the ENV variables. It was fairly straightforward to do this manually when you start the rails server (below), but getting the ENV variables in there automatically at setup was harder.
PUBLISHABLE_KEY=pk_foo SECRET_KEY=sk_bar rails s
The answer was to get the ENV variables into my ~/.bash_profile which took some yak shaving, but here is the best place to start. http://stackoverflow.com/questions/7501678/set-environment-variables-on-mac-os-x-lion
So far things have been easy, but we just followed the Stripe tutorial, there is no User involved yet. For simplicity, maybe user experience, I want:
- The User to enter their credit card at signup,
- A single payment plan (for now),
- Every User to give a credit card.
So if the person is a User and can login, then they have paid with a credit card. Stripe has really good subscriptions built in, and again, their documentation is really good, but the documentation isn’t the complete picture and it takes some thought to bring in the Devise setup. https://stripe.com/docs/tutorials/subscriptions
I found an interesting tutorial that outlined how I wanted things to work, although simply copying and pasting into my app wasn’t going to work and the tutorial is incomplete. http://blogs.clogeny.com/stripe-integration-with-rails-application/ It helped me understand a few of the processes better and seemed to have the right approach.
I found myself continuously referencing the Stripe tutorials along with the guide from Clogeny.
Stripe = https://stripe.com/docs/checkout/guides/rails and https://stripe.com/docs/tutorials/subscriptions
Clogeny = http://blogs.clogeny.com/stripe-integration-with-rails-application/
Following the Clogeny process with some corrections and different ideas…
Step 1: Stripe Gem- Installing the gem should be done already if you’ve built the single charge from the Stripe guide.
Step 2: ENV variables – These should already be done from the single-charge test. You also want to follow best practices for ENV variable and not put the in code that might end up on github. Also pay attention to the different variable names in this guide. It looks like the Stripe.api_key (Clogeny) is related to the Stripe secret key, but the initializer is different in the Clogeny guide. I stuck with the initializer code from the Stripe guide.
Step 3: Include the JS in your layouts file. I needed to change the syntax to get mine to work. Here is the code that worked for me.
Step 4: Add the Stripe publishable_key to the application page. Mine looks much different from the Clogeny guide.
app/views/layouts/application.html.erb (same page as above)
I’m not sure how much the order matters, but you can see my code here https://github.com/mikesabat/capecod/blob/stripe_setup/app/views/layouts/application.html.erb At this point I would load the signup page and see if the publishable_key shows up when you Inspect the page elements.
Step 5: New User Form – Now we are getting somewhere. We want to add the hidden field and the credit card form to our signup page. I already had the User model form built so I tried to match the styles as much as possible.
Step 7: Controllers – It was a little tricky figuring out Controller actions, once the form is submitted. Devise doesn’t create a User Controller, so this takes a little work to figure things out. We need to add a stripe_card_token to the User Model, but we can’t just list that as attr_accessible. Rails 4 introduces strong parameters and setting up attributes on the Devise User is a little different. Here is the documentation. https://github.com/plataformatec/devise#strong-parameters
This code in app/controllers/application_controller.rb will let the app add or edit parameters on the User Model during signup and edit actions.
Step 8: User Model – Before the user is created Stripe is grabbing the credit card information, supplying a token and we attach that token to the User Model as the User is created. We still need to subscribe the User to the subscription plan and charge the card. Stripe has great documentation on this https://stripe.com/docs/tutorials/subscriptions I’d recommend creating the plan on the dashboard, as it is so easy.
My code matches Stripe’s example pretty closely, but there are two differences. First, I don’t have the API key in my model, but it still works. Second, for the :plan attribute, Stripe wants the ID number, not the plan name. I think their documentation is incorrect in that respect.
Once this is set up you should be able to test out the signup process and see the charges and Customers being added on Stripe.
Step 9: Error Messages – After putting through a number of successful transactions and watching the fake money pile up on Stripe, I decided to test out a bad credit card number and I didn’t see what I expected. My normal debugging methods didn’t work because the problem was in the JS and nothing appeared on the server logs. A friend helped me make this work.
This says that if Stripe does not return a 200 status (good credit card), then we should find the div with class=stripe_error and display it. It will look for this div on the User registration page.
There is some tricky stuff, specifically ‘style=’display:none” in the div, and canceling that in the JS, but if you copy what I have it should work well.
This is a lot of information, and I hope it helps. There is still more (like getting this to run on Heroku), but this is a good start. If you’re building something cool and this helps, please link to it in the comments. Here is the code for my app so far. https://github.com/mikesabat/capecod
If you made it this far, please give me an upvote on HN https://news.ycombinator.com/item?id=6910591
After a year-long course trying to learn the basics of Ruby I’m moving on to learn Rails. I definitely would not say that I have a firm understanding of the Ruby language, or even the concepts, but I’ve learned how to google a few things. For Rails I’m using the Head First book which is a super graphic and sing-songy way to learn. It’s corny, but pretty good at helping you actually build things that you may be able to use.
In the first chapter there were a few snafus that I was able to get around with some help from the internet. First, this book is old, it’s been sitting on my desk for at least a year. In that time, a new version of Rails has been released which made things tricky. I believe the first command on the first page didn’t work because there is different syntax with Rails 3. Great!!!
I found a site that was a huge help. The blog is written by Tim van Gelder and he’s made a simple spreadsheet of the syntax changes. Find it here http://timvangelder.com/2012/02/25/using-head-first-rails-with-rails-3-x/ This was great and a quick fix.
My second issue was a bit tougher. I was so excited with my new powers that I accidentally ordered Rails to create a table, but I didn’t add any fields to the table. Of course with the scaffold command I didn’t know how to do-over. I guess that I should have just generated a migration to add fields to the table, but I wanted to do this the hard way.
I was actually able to delete the table that I created in the database SQLite3. I found a post on http://dashdingo.org/post/1627307077/sqlite3-sqlexception-table-already-exists that helped me do this. One thing to note is that Rails names the database table as a plural. I knew the website address was plural, but it wasn’t clear that the actual table is named the plural as well.