Posted on 14 December 2016 by Luke
A few years ago I worked with a startup were our mission was to make ordering your coffee as convenient as possible by being able to place your order and pay for it with your phone. You could do this while being on the train into work and then pick up your order as you made your way into the office. I have experienced myself a number of times, that I would place an order while still being on the bus on my way into work, about 5 minutes before my stop. I would get off the bus and walk down the street to the coffee shop, walk past a queue of about 5 or 6 waiting customers, being greeted by name and handed my coffee, I would thank the barista and walk out. The look on the faces of some of those waiting in line is hard to describe.
An integral part of the software system we were building back then revolved around sending notifications to our customers. There were a number of ways an order could be placed, not just through the mobile app but also through the website, which meant that we could not always send the same type of notification, i.e. a mobile push notification. It basically meant that based on how an order was placed and what type of information we had regarding our customer we would send them either a mobile push notification (fast & cheap), an SMS (fast but expensive in comparison) or an email (cheap, but might not be noticed by some customers until much later, i.e. high latency).
So, based on these constraints we built a part of the system that we dubbed "the customer communication manager" and it was basically responsible of sending notifications to customers who had placed an order. When an order was placed, it would check how the order was placed (app vs website) and what kind of information we had regarding that customer and then either send them a mobile push, an SMS or an email.
All this worked great but while working on this problem we observed one very important problem that was going to come back and haunt us: The text for all our messages was stuck in source code and therefore difficult to maintain. Everytime there was a copy change or tweak to the message text, a developer basically had to go in and make that change. We either then had to redeloy on the spot or wait until the next update window. This was going to be a problem indeed and it was further compounded by the fact that our HTML email templates were stored with our marketing email provider which only had support for simple variable insertion. For our customer order emails, which listed a detailed table of all items purchased, this was a big problem. It meant that for HTML emails we had the email layout stored externally and we had to generate the HTML on our backend which was then inserted into a single variable of the template before sending the email. Ouch. Imagine what happend when the email layout was redesigned..
Many of you will have worked on applications that send out messages to users. We typically end up integrating with one or a few of the many services that exist for this exact purpsose, a task which we as developers would classify as trivial. There are services that will make it easier to send out emails by providing an easy to use API or SMTP endpoint with which your application can easily integrate. Similar services exist for sending SMS text messages and mobile push notifications. However, no matter how great all of these services are at making our lives easier and saving us time as developers, they usually all have the same fundamental flaw; we end up with the message text stuck in our source code and this means that everytime there is a copy tweak or another text change a developer has to go in and make that change. For small systems this might be doable, but for larger systems with a larger team it can become a burdensome chore.
Postways tries to solve this problem by focusing on managing the message content rather than the infrastructure over which the message is send. In fact, to use Postways you need to bring your own means of transport. We currently fully support Amazon AWS and any SMTP endpoint with more providers planned for the future. This basicially means that you can think of Postways as a higher level of abstraction to other transactional email or message services. Postways will send email, SMS and mobile push messages through your AWS account. Postways provides a space where all members of a product team can manage the message content. In a way, Postways is like a content management system for messages.
We certainly hope you'll give Postways a try. To get started we have documentation available which we're always in the process of improving. For any other questions or feedback, please feel free to reach out to support.