In the age of hyper-personalization by the likes of Amazon and Netflix, customized user experiences are now table stakes for digital platforms. Businesses that invest in personalization are rewarded with loyalty and revenue. Those that don’t, get left behind.

But making that investment isn’t a straightforward affair. Many services that pitch themselves as personalization tools don’t even come close to creating a truly customized experience. And today’s savvy web users aren’t fooled:

• 74% of customers feel frustrated when website content isn’t personalized.
• 84% of consumers say being treated like a person, not a number, is important to winning their business.

Where we’ve seen businesses stumble is in substituting personification for true personalization. While personalization involves tailoring content based on direct personal information, personification is based on categories of consumers, not individual people.

Here’s what you need to know about the difference.

Perils of Personification

Gartner defines personification as “the delivery of relevant digital experiences to individuals based on their inferred membership in a defined customer segment, rather than their personal identity.” It’s the digital equivalent of calling someone “buddy” or “champ” because you can’t remember their name. I know that I know you, but I don’t know who you are.

Personification tools can track user behavior and use AI to place users into, say, one of several marketing personas you’ve developed. But in terms of driving meaningful, personalized interactions with users, personification falls down.

Here are a few critical issues with commonly used personification tools:

User Session Data

Information about a user’s interactions with an application is stored temporarily on the application’s server, not the browser.

EXAMPLE: During this session, I see that you’ve visited a piece of content that falls in a specific category. For the rest of your session, I can serve up other content tagged with the same category (often in Featured, Related, or You May Also Like sections).

PROBLEM 1: As soon as the browser session is closed, the user data is lost.

PROBLEM 2: The moment you switch from one device (e.g. mobile) to another (e.g. tablet) you lose all session data.

Contextual Data

Marketing automation or location intelligence software can use AI to gather environmental data about a user to deliver customized content or services.

EXAMPLE: I see that you’re in Los Angeles, California. Knowing your local weather, time zone, and other regional attributes, I can tailor the content you see to be more specific to your area.

PROBLEM: I have to ask you first if I can track your location, and you might say no.

First Party Cookie Data

By storing information about a user’s behavior directly on a domain, site owners can collect analytics data and remember language settings, among other functions.

EXAMPLE: Last time you visited my website, you commented on a certain piece of content. I may even have asked, “Do you want to see more of this type of content?” Now that you’re back, I can serve up newly published content of the same type. I can even feature it right on the homepage.

PROBLEM 1: I need to ask you if I can use cookies with you, and you can say no.

PROBLEM 2: If you clear the cookies in your browser, I’ll lose that valuable data.

PROBLEM 3: Another family member is using the same application on the same device, and now I’m getting mixed signals. This is completely messing with my AI.

Bottom line: personification is not really personalization. Even worse, you may lose your data and have to start from square one. To deliver true personalization, you need first-party data from authenticated users. Instead of guessing who your customer is, get to know who they really are.

Next-Level Personalization

True personalization is difficult to achieve outside of a digital platform, where people register as users (versus just casually visiting a website). Once someone becomes an authenticated user, it’s easier to learn a number of things about them.

83% of consumers are willing to share their data to enable personalized experiences. Platform users in particular are more open to providing personal information, because they’re specifically looking for a customized experience. With that first-party data, you can track preferences and interactions to improve the user experience. And you’re not going to lose the historical data when a user closes a session or clears their cookies.

Here are some key benefits:

• I actually know who you are, and over time I can continue to learn more about you and your interests. Plus, I’ll only lose that data if you quit my tool, service, or platform.
• Your data follows you across any devices where you use my application (mobile, tablet, desktop, etc.).
• I can start a two-way conversation with you, so you can tell me how you want to personalize your experience and what kind of content you want to see.
• I can reach out to you with personalized suggestions, driving more engagement and giving you a reason to return more often.
• While you can always say no to first-party cookies if you have privacy concerns, by signing up for my platform, you’re indicating a level of trust and consent.

Looking for Middle Ground?

In the end, you’ll deliver the best personalization (and earn the most engagement) by building an interactive platform and leveraging first-party data. But what if you have a decent website, and you’re not ready to shift to a platform?

You could approach it as a testing ground for personalization instead. By creating a series of micro-interactions using personification tools, you can test whether your users actually want a personalized experience, and if so, what they want to personalize.

Let’s say you’re a news outlet. You could just let people come and read your content online. At the next level, you can try to guess who they are through personification (via cookie requests, location prompts, etc.). If users are interacting with your prompts, it’s likely they’re interested in having a personalized experience.

Finally, you could build a platform for registered users and offer true personalization. You’ll not only deliver a better user experience, you’ll increase engagement and return visits — not to mention sales and other revenue.

At whatever level you can, go the extra mile and give your users what they want. We’re happy to help! Contact us today to learn more.

You’ve decided to decouple, you’re building your stack, and the options are limitless – oh, the freedom of escaping the LAMP square and the boundaries of the conventional CMS! Utilities that were once lumped together into one unmoveable bundle can now be separately selected, or not selected at all. It is indeed refreshing to pick and choose the individual services best fitted to your project. But now you have to choose.

One of those choices is your backend content storage. Even though decoupling means breaking free from monolithic architecture, certain concepts persist: content modeling, field types, and the content editor experience.

I recently evaluated four headless CMS options: Contentful, Cosmic, Dato, and Prismic. Prior to that, I had no experience with any of them. Fortunately they all offer a free plan to test and trial their software. For simpler projects, that may be all you need. But if not, each CMS offers multiple tiers of features and support, and costs vary widely depending on your requirements.

I was tasked with finding a CMS and plan that met the following specs:

• 10 separate content editors
• Multiple editor roles (admin, contributor, etc…)
• Draft/scheduled publishing, with some sort of editorial workflow, even as simple as limiting a role to draft-only status

Although this doesn’t seem like a big ask for any CMS, these requirements eliminated the free plans for all four services, so cost became a factor.

Along with cost, I focused my evaluation on the editor experience, modeling options, integration potential, and other features. While I found lots of similarities between the four, each had something a little different to offer.

It’s worth mentioning that development is active on all four CMSs. New features and improvements were added just within the span of time it took to write this article. So keep in mind that current limitations could be resolved in a future update.

Contentful

Contentful’s Team package is currently priced at $489 per month, making it the most expensive of the four. This package includes 10 content editors and 2 separate roles. There is no editorial workflow without paying extra, but scheduled publishing is included.

What I love

The media library. Media of many different types and sources – from images to videos to documents and more – can be easily organized and filtered. Each asset has a freeform name and description field for searching and filtering. And since you can provide your own asset name, you’re not stuck with image_8456_blah.jpeg or whatever nonsense title your asset had when you uploaded it. Additionally, image dimensions are shown on the list view, which is a quick, helpful reference.

What I like

Commenting. Every piece of content has an admin comments area for notes or questions, with a threaded Reply feature.

My Views. My Views is an option in the content navigation panel. With a single click, you can display only content that you created or edited – very convenient when working with multiple editors and a large volume of content.

What could be better

Price. Contentful is expensive if your project needs don’t allow you to use the free/community plan. You do get a lot of features for the paid plans, but there’s a big jump between the free plan and the first tier paid plan.

Cosmic

Cosmic ranks second most pricey for our requirements at $299 per month for the Pro Package. This package includes 10 editors and 4 predefined roles. It has draft/scheduled publishing, and individual editor accounts can be limited to draft status only.

What I love

Developer Tools. Developer Tools is a handy button you can click at the object or object type level to view your REST endpoint and response. It also shows other ways (GraphQL, CLI, etc.) to connect to a resource, using real code that is specific to your bucket and objects.

The Slack Community. The Cosmic Slack community offers a convenient way to get technical support – in some cases, even down to lines-of-code level support – with quick response times.

What I like

View as editor. This is a toggle button in the navigation panel to hide developer features – even if your account is assigned the developer or admin role – allowing you to view the CMS as the editor role sees it. This is useful for documenting an editor’s process or troubleshooting their workflow.

Extensions. Cosmic provides several plug-and-play extensions, including importers for Contentful and WordPress content, as well as Algolia Search, Stripe, and more. I tested the Algolia extension, and it only took minutes to set up and immediately began syncing content to Algolia indexes¹. You can also write your extensions and upload them to your account.

What could be better

Price/price structure. I found Cosmic’s pricing structure to be the most confusing, with extra monthly charges for common features like localization, backups, versioning, and webhooks. It’s hard to know what you’ll actually pay per month until you add up all the extras. And once you do, you may be close to the cost of Contentful’s lower tier.

Content model changes. Changing the content model after you’ve created or imported a lot of content is tricky. Content model changes don’t flow down to existing content without a manual process of unlocking, editing and re-publishing each piece of content, which can be very inefficient and confusing.

Dato

Dato’s Professional package is priced at €99 (about $120) per month, making it the second least pricey for our requirements. It includes 10 content editors and 15 roles, with configurable options to limit publishing rights.

What I love

Tree-like collections. Dato lets you organize and display records in a hierarchical structure with visual nesting. The other CMSs give you roundabout ways to accomplish this, usually requiring extra fields. But Dato lets you do it without altering the content model. And creating hierarchy is as simple as dragging and dropping one record under another, making things like taxonomy a breeze to build.

What I like

Maintenance Mode. You can temporarily disable writes on your project and display a warning message to logged in editors. If you need to prevent editors from adding/editing content — for instance, during content model changes — this is a useful feature.

What could be better

Field types. Out-of-the-box Dato doesn’t provide field types for dropdowns or checkboxes. There’s a plugin available that transforms a JSON field into a multiselect, but it’s presented as a list of toggles/booleans rather than a true multiselect. And managing that field means working with JSON, which isn’t a great experience for content editors.

Dato is also missing a simple repeater field for adding one or more of something. I created repeater-like functionality using the Modular Content field type, but this feels overly complicated, especially when every other CMS in my comparison implements either a Repeater field type (Cosmic, Prismic) or a multi-value field setting (Contentful).

Prismic

Prismic ranks least pricey, at $100/mo for the Medium Package. This package includes 25 content editors, 3 predefined roles, draft/scheduled publishing and an editorial workflow.

What I love

Field types. Prismic gives you 16 unique field types for modeling your content, but it’s not the number of types that I love; it’s the particular combination of options: the dedicated Title type for headings, the Media link type, the Embed type, the Color Picker. Plus, the UI is so intuitive, content editors know exactly what they’re expected to do when populating a field.

Take the Title type for example. If you need a heading field in the other CMSs, you’d probably use a plain text or rich text field type. Using rich text almost guarantees you’ll get unwanted stuff (paragraph tags, in particular) wrapped around whatever heading the editor enters. Using plain text doesn’t let the editor pick which heading they want. Prismic’s Title type field solves both of these problems.

Price. Unlimited documents, custom types, API calls and locales are included in the Medium package for a reasonable price. Additionally, Prismic has more packages and support tiers than any of the others, with one paid plan as low as $7/mo.

What I like

Slices. Slices are an interesting addition to back-end content modeling, because they’re essentially components: things you build on the front. Prismic lets you create custom components, or use their predefined ones — blockquotes, a list of articles, an image gallery, etc… I admit I didn’t test how these components render on the front-end, but Slices deserve further exploration.

What could be better

Integration options/plugins. Although Webhooks are included in all of Prismic’s plans, there doesn’t seem to be any development of plugins or ways to quickly extend functionality. Every other CMS in this comparison offers simple, click-to-install extensions and integrations to common services.

A note on Front-end Frameworks

A headless CMS, by simple definition, is a content storage container. It does not provide the markup that your website visitors will see and use. Therefore, your project planning will include choosing and testing a front-end system or framework, such as Gatsby JS. It’s important to find out early in the process what, if any, obstacles exist with connecting your choice CMS to your choice front-end.

At Oomph, we’ve successfully used both Contentful and Cosmic with a Gatsby front-end. However, Gatsby plugins exist for Prismic and Dato as well.

Summary

As with any decoupled service, your headless CMS choice will be determined by your project’s distinct requirements. Make sure to build into your project plan enough time to experiment with any CMS options you’re considering. If you haven’t worked with a particular CMS yet, give yourself a full day to explore, build a sample content model, add some content and media, and test the connection to your front-end.

Does a clear winner emerge from this comparison? I don’t think so. They each succeed and stand out in different ways. Use this article to kickstart your own evaluation, and see what works for you!

At the time of this writing, there are some field types that the extension doesn’t pass from Cosmic to Algolia.

If you live in an area with a lot of freight or commuter trains, you may have noticed that trains often have more than one engine powering the cars. Sometimes it is an engine in front and one in back, or in the case of long freight lines, there could be an engine in the middle. This is known as “Distributed power” and is actually a recent engineering strategy. Evenly distributed power allows them to carry more, and carry it more efficiently.¹

When it comes to your website, the same engineering can apply. If the Content Management System (CMS) is the only source of power, it may not have enough oomph to load pages quickly and concurrently for many users. Not only that, but a single source of power may slow down innovation and delivery to multiple sources in today’s multi-channel digital ecosystems.

One of the benefits of decoupled platform architecture is that power is distributed more evenly across the endpoints. Decoupled means that the authoring system and the rendering system for site visitors are not the same. Instead of one CMS powering content authoring and page rendering, two systems handle each task discreetly.

Digital properties are ever growing and evolving. While evaluating how to grow your own system, it’s important to know the difference between coupled and decoupled CMS architectures. Selecting the best structure for your organization will ensure you not only get what you want, but what is best for your entire team — editors, developers, designers, and marketers alike.

Bombardier Zefiro vector graphic designed for Vexels

What is a traditional CMS architecture?

In a traditional, or coupled, CMS, the architecture tightly links the back-end content administration experience to the front-end user experience.

Content creation such as basic pages, news, or blog articles are created, managed, and stored along with all media assets through the CMS’s back end administration screens. The back end is also where site developers create and store customized applications and design templates for use by the front-end of the site.

Essentially, the two sides of the CMS are bound within the same system, storing content created by authenticated users and then also being directly responsible for delivering content to the browser and end users (front end).

From a technical standpoint, a traditional CMS platform is comprised of:

1. A private database-driven CMS in which content editors create and maintain content for the site, generally through some CMS administration interfaces we’re used to (think WordPress or Drupal authoring interfaces)
2. An application where engineers create and apply design schemas. Extra permissions and features within the CMS give developers more options to extend the application and control the front end output
3. A public front end that displays published content on HTML pages

What is a decoupled CMS architecture?

Decoupled CMS architecture separates, or decouples, the back-end and front-end management of a website into two different systems — one for content creation and storage, and another for consuming content and presenting it to the user.

In a decoupled CMS, these two systems are housed separately and work independently of the other. Once content is created and edited in the back end, this front-end agnostic approach takes advantage of flexible and fast web services and APIs to deliver the raw content to any front-end system on any device or channel. It is even possible that an authoring system delivers content to more than front-end (i.e. an article is published in the back-end and pushed out to a website as well as a mobile App).

From a technical standpoint, a decoupled CMS platform is comprised of:

1. A private database-driven CMS in which content editors create and maintain content for the site, generally through the same CMS administration interfaces we’re used to — though it doesn’t have to be²
2. The CMS provides a way for the front-end application to consume the data. A web-service API — usually in a RESTful manner and in a mashup-friendly format such as JSON — is the most common way
3. Popular front-end frameworks such as React, VueJS, or GatsbyJS deliver the public visitor experience via a Javascript application rendering the output of the API into HTML

Benefits of decoupled

By moving the responsibility for the user experience completely into the browser, the decoupled model provides a number of benefits:

Push the envelope

Shifting the end-user experience out of the conventions and structures of the back-end allows UX Engineers and front-end masterminds to push the boundaries of the experience. Decoupled development gives front-end specialists full control using their native tools.

This is largely because traditional back-end platforms have been focused on the flexibility of authoring content and less so on the experience of public visitors. Too often the programming experience slows engineers down and makes it more difficult to deliver an experience that “wows” your users.

Need for speed

Traditional CMS structures are bogged down by “out-of-the-box” features that many sites don’t use, causing unnecessary bloat. Decoupled CMS structures allow your web development team to choose only what code they need and remove what they don’t. This leaner codebase can result in faster content delivery times and can allow the authoring site to load more quickly for your editors.

Made to order

Not only can decoupled architecture be faster, but it can allow for richer interactions. The front-end system can be focused on delivering a truly interactive experience in the form of in-browser applications, potentially delivering content without a visitor reloading the page.

The back-end becomes the system of record and “state machine”, but back-and-forth interaction will happen in the browser and in real-time.

Security Guard

Decoupling the back-end from the front-end is more secure. Since the front-end does not expose its connection to the authoring system, it makes the ecosystem less vulnerable to hackers. Further, depending on how the front-end communication is set up, if the back-end goes offline, it may not interrupt the front-end experience.

In it for the long haul

Decoupled architectures integrate easily with new technology and innovations and allow for flexibility with future technologies. More and more, this is the way that digital platform development is moving. Lean back-end only or “flat file” content management systems have entered the market — like Contentful and Cosmic — while server hosting companies are dealing with the needs of decoupled architecture as well.

The best of both worlds

Decoupled architecture allows the best decisions for two very different sets of users. Content editors and authors can continue to use some of the same CMSs they have been familiar with. These CMSs have great power and flexibility for content modelling and authoring workflows, and will continue to be useful and powerful tools. At the same time, front-end developers can get the power and flexibility they need from a completely different system. And your customers can get the amazing user experiences they have come to expect.

The New Age of Content Management Systems

Today’s modern CMS revolution is driving up demand for more flexible, scalable, customizable content management systems that deliver the experience businesses want and customers expect. Separating the front- and back-ends can enable organizations to quicken page load times, iterate new ideas and features faster, and deliver experiences that “wow” your audience.

1. Great article on the distributed power of trains: Why is there an engine in the middle of that train?
2. Non-monolithic CMSs have been hitting the market lately, and include products like Contentful, CosmicJS, and Prismic, among others.

We’ve dreamed about having conversations with our computers for a long time. Stanley Kubrick’s 1968 film 2001: A Space Odyssey imagined a sentient computer named Hal. In the past few years, with the rise of Siri, Alexa and more, we live in that reality.

A simpler version of the natural language processing apps like Siri are chatbots. 2016 was the rise of the chatbot, and 2017 will continue that trend, with more and more users having “conversations” via the keyboard to find information and complete tasks instead of clicking around in search engines and on websites. Some of us have not yet interacted with a chatbot before, so, what is it like? And what is it like to design one?

The experience of interacting with a chatbot is very similar to interacting with a smart and eager-to-please dog — the bot understands a lot, but won’t always give you the feedback that you expect; their intentions are good, but they are not always helpful; and you end up training yourself as much as you try to train them.

When it comes to designing one, it is very much like training a dog as well. Since there is no visual interface, the tools of brand are limited to the voice and tone of the snippets of conversation that the bot can have. If you are lucky, there might be an avatar that the bot can use, but beyond that, the “personality” of the bot comes solely from the way it reacts and the words that it uses.

No UI is still a UI

First, a slight tangent, if I may.

There is a saying, coined by Golden Krishna, that goes The best user interface is no user interface, or, The Future of UI is no UI. While on the surface, that is a nice, catchy statement, I don’t think it is true. To get semantic, I’d refine that to say The Future of UI is no GUI.

The absence of a graphical user interface (GUI) is still an interface. If your bot uses Facebook Messenger, or WeChat, or Slack, it still has a GUI. It’s just not one that you designed, and you have to work within the constraints of that system.

Further, I would argue that a Conversational UI is still a UI. How could it not be? To design one, you need to make the same decisions that you would if you were designing anything else — there are just a lot more constraints to work within.

You can’t choose the typeface, you can’t rely on colors, or design details such as borders, drop shadows, and the like. Instead, your UI and all the personality of this little bot comes through in the way it can have a conversation. It would be a very different experience to have the bot use a military tone of voice — gruff, coarse, quick and to the point with very few conversational niceties — than if you used a friendly, happy, and more naturally intoned voice.

A Conversational UI may not be a graphical UI, but it is still a UI. There are decisions to be made, but because there are no visuals to work with, the decisions you make are even more crucial to the expression of your bot’s personality and the brand that you want it to reflect.

Our good little boy, Gitpup

As a way to experiment with Conversational UIs, and as a way to create something useful for our team that might also have usefulness in the larger marketplace, Oomph designed, built, and implemented a chatbot for <a href=”//slack.com”target=”blank” rel=”noopener noreferrer” title=”Opens in a new window”>Slack (a Slackbot) and <a href=”//www.hipchat.com”target=”blank” rel=”noopener noreferrer” title=”Opens in a new window”>Hipchat called <a href=”//www.gitpup.io”target=”_blank” rel=”noopener noreferrer” title=”Opens in a new window”>Gitpup.

The problem that we wanted to solve was “How do you make peer-to-peer code review easier to manage and more fun?” As the name suggests, Gitpup is an assistant that we connect to our Github account. Its job is to announce when a Pull Request is ready for review, assign it to someone, track it, and then close it when the review is approved. Once a review has been completed, the user is given “karma” points that come with bragging rights and have become a currency of sorts amongst our team.

Designing the chatbot

Our “design” and personality came from who we decided that this bot was. We toyed with a bunch of ideas, but once we decided that the bot was a dog, it was easy to start to have some fun with it.

As a dog, Gitpup is everything you would want one to be: helpful, quick to respond, and obedient. But Gitpup has a little sass, too. We wanted it to have some personality, and be somewhat of a jokester. It has random phrases that it throws back at you if you mention it by name, and while the randomness is uncontrollable by nature, it does lead to some fun interactions.

A sample conversation with Gitpup

	nate whats unassigned
	Gitpup APP No open, unapproved and unassigned Pull Requests
	nate Thanks gitpup
	Gitpup APP You’re welcome, nate!
	nichole hey gitpup
	Gitpup APP See if I play fetch with you next time, @nichole
	nichole y r u so mean?

It utters plenty of encouragement when a Pull Request is taken or completed by a team member.

Sample workflow with Gitpup

	Gitpup APP [Review #3366] marc has been assigned to Bring react ish into main oomph repo!, #233 on oomphinc.com. Go get ’em, Champ!
	Gitpup APP [Review #3364] brett closed and merged Add logintoboggan module, #269 on drupal-repo +1 Karma (1,766) Yes. You. Can!
	Gitpup APP [Review #3365] brandon approved PR Add style for when there are logos in a grid within content (SASS), #207 on kab. Magnifique!
	Gitpup APP [Review #3365] Thanks for participating, brandon +5 Karma (903). Woof!

We also built some randomness into the daily grind. In addition to helping with reviews, assignments, and approvals, Gitpup announces a Raffle for any Karma that might be unassigned once a day at a random time. You can type I’m in or I’ll join to enter the raffle.

Joining Gitpup’s daily Karma raffle

	Gitpup APP Attention Today’s community Karma raffle is in effect! Say I’m in! to join the raffle within the next 5 minutes to join for your chance to win 45 Karma!
	nate I’m in
	Gitpup APP Thanks for joining, @nate, you’re the first and only participant in this raffle, Purrrrrfect! Chances are looking good!
	nichole im in
	Gitpup APP Fingers crossed, @nichole! There are now 2 participants in this raffle.
	brett ill join
	Gitpup APP This could be the one, @brett! There are now 3 participants in this raffle.
	stephen I’m in as well
	Gitpup APP May the odds be ever in your favor, @stephen! There are now 4 participants in this raffle.
	Gitpup APP And the winner of today’s raffle is… @nathandentzau! Congratulations! +45 Karma

After interacting with Gitpup for a few days, it is easy to forget that it is just a bot that we programmed. Personality is an easy thing to create if you start from a place of authenticity. For us, we were not trying to create a person, we simply wanted an amiable cartoon character that would be fun to interact with and make what might be a dreary task into something a little more engaging.

A well-trained Bot will also train the User

This little experiment into Conversational UIs helped show us how any UI will also train the user in ways to get the most out of it. With a visual UI, it might be lots of trial and error — clicking around to get a sense of what things are and where they go. With Gitpup, it was the same sort of trial and error, but the downside is that a command can simply go unnoticed if it is not in the bot’s vocabulary.

For instance, our patterns match phrases with a certain degree of fuzziness — we ignore punctuation and plurals, just so the commands don’t have to be perfectly typed. To ask Gitpup which PRs are not assigned to someone yet, you can type “whats unassigned” and Gitpup will respond. There is a drawback to a Slackbot that is in an open room where other conversations are happening — you don’t want it to respond to everything that anyone says, so, if you try to get Gitpup’s attention but don’t use the right terms, you won’t get any response.

Users can quickly learn the different commands that a simple bot will recognize, and it’s not so bad to use trial and error to figure it out. But with a more complicated bot that you are in a direct conversation with (via a text app), it can be a little more awkward if your bot does not recognize a lot of natural language. Be sure to design some phrases in the bot’s conversational database that can be used when it does not understand something, or it can not complete a particular task. Success messages are easy to create, but it is harder to create a failure message that does not frustrate a user or make them think that the bot is simply useless.

	brett gimme 4034
	Gitpup APP Ruh roh, I don’t know about Review #4034
	nichole give 3466 to @thatguy
	Gitpup APP Darn, I don’t know who that is!

When is a Chatbot right for you?

While chatbots are all the rage right now, I don’t think normal point and click websites are going away anytime soon. A chatbot service isn’t right for everyone because the service they offer is very transactional in nature—get me this, research that. They can offer information that a user didn’t know that they wanted, but that is often more complicated, and in the end, the user needs to opt into the service somehow.

The questions you can ask are:

• How complex is your service? Would the simple conversational style of a chatbot be helpful for your customers, or frustrating?
• Can you imagine having a conversation with your service? What would it sound like? Are visuals necessary to the experience?
• Would your brand identity translate into a “personality” for a bot? Can you imagine what the “voice” of the service might sound like?
• Where are your customers? Are they likely to already use a message service like Facebook Messenger, WeChat or Slack? Do you want to be where they are?
• Are your customers likely to have an Amazon Echo or Google Home device? Is your service better suited as an add-on to these personal assistants?
• Will customers need to authorize a purchase? Will you need to create your own checkout experience, or can you leverage a pre-existing service like Amazon?
• Do you want your service to work over SMS? Will the limitations of text messaging (message length, possible fees for users) hinder the app’s functionality?

Find a Chatbot and Use it!

If you are a marketer looking for new ways to connect with customers, or a manager looking for tools to keep employees efficient and engaged, you should become familiar with chatbots. We’d recommend these as good starting points:

• Gitpup (of course): if you manage a development team that works with GitHub
• x.ai: A personal assistant chatbot that works by being CC’ed on your emails
• healthtap.com: A Facebook Messenger bot that answers your medical questions and is backed up by real people
• meetcleo.com: A SMS chatbot for managing your money
• assi.st: An integrated platform of bots that work for Google Home, Messenger, Twitter, and Alexa.

The barriers between our computers and our normal everyday interactions are coming down. A computer that can hear your voice commands is probably not far away from you at any given time. Conversational UIs are making it easier to get what you need at any moment without finding a particular app, typing on a tiny screen, or doing a lot of clicking around. They become another tool in the belt and another way to be where your customers are.

If you’d like more information about chatbots and whether or not your company can benefit from the power of No GUI, drop us a line. We’d love to chat person to person. 😉

More reading about chatbots:

• The best interface is no interface: why we don’t always need An App for That
• Chatbots : Start here! (February 2017—updated)
• Conversational UI Principles — Complete Process of Designing a Website Chatbot
• How Artificial Intelligence Is Democratizing The Personal Assistant