.jpg/:/cr=t:0%25,l:0%25,w:100%25,h:100%25/rs=w:1209,h:806)
A chatbot is a product, a conversation is an experience
Conversation Design
Writing bot dialogue can be similar to writing lines for a play that a digital actor then delivers. But you also have to write your customers' lines and they don't get the script. Oh, you also have to build the theatre, and the stage, and teach the actor how to talk, and critique its performance, and...
Understanding your use case
Why do you really want to build a conversational interface?
Crisply defining your bot's objective will inform which flows you build and how you measure success. For now, forget packaging this in a way you can sell to stakeholders, you can worry about that later.
Just ask yourself, "What need this product is meeting for my business?"
- Increasing self help to lower operating costs
- Qualifying sales leads
- Helping users navigate overly complex UIs or huge knowledge bases
- Demonstrating technical prowess to stay competitive
- Something else entirely?
Chances are you may have a few of those going on in varying degrees. Rank your top priorities and align on them with key stakeholders. When it's time to report on performance, you'll need to craft data stories that speak to that need, even if you have to phrase it more prettily.
Understanding your users
Who are they?
You need to understand your customers as completely as the character you will create to serve their needs. UX writers create user personas for this, you should do the same.
What do they need?
Understanding who they are will tell you the what drives them. When you think through their motivations and end goals of using your products/services, and scour all available data points to discover what they're telling you they need help with, you'll start to see stories emerge on how to make the most impact with conversational automation.
What are their obstacles?
No matter what it is, they think its you. Of course, they may be their own obstacle. More often than not, people decide how to act based on emotion, then use logic to justify the decision they've already made. If you want a bot to influence their behavior (altruistically of course, always use your powers for good) it must elicit empathy FROM your user. Not the other way around. This is where character creation becomes incredibly important.
Creating an AI Character
Who they are
What they "learn"
How they help
The best person for the job
Gender:
In general, I feel businesses should have gender-less bots.
Assigning a gender to a machine feels like a lie and brings up all kinds of bias questions that detract from the task at hand.
Bots are machines. Addressing that early and often keeps you out of creepy territory.
If you have a good reason, by all
The best person for the job
Gender:
In general, I feel businesses should have gender-less bots.
Assigning a gender to a machine feels like a lie and brings up all kinds of bias questions that detract from the task at hand.
Bots are machines. Addressing that early and often keeps you out of creepy territory.
If you have a good reason, by all means, gender your character. Heck, my profile bot is "female" because she's modeled after me. Just make sure your reason is compelling.
Traits:
Pick three traits you'd want in the person you'd hire for this job if you were hiring a human rather than building a bot.
Define how they will speak that show those traits..
Behaviors:
Pick three things they'll consistently do, and define how they'll do them, that demonstrate those traits
How they help
What they "learn"
How they help
Automate Repetitive Requests
FAQs:
Investigate your options for connecting your bot up to knowledge bases. You can save a lot of time and energy building new content, if you can map to what you've already got.
That being said, I personally feel that if the mmain function is mapping to existing content, you may be under utilizing the superpow
Automate Repetitive Requests
FAQs:
Investigate your options for connecting your bot up to knowledge bases. You can save a lot of time and energy building new content, if you can map to what you've already got.
That being said, I personally feel that if the mmain function is mapping to existing content, you may be under utilizing the superpowers of the tool.
Conversation is so much more than information. You should be mixing methodologies.
API Actions:
Get you a good engineer, work out how to use information you already have about your users; account information, cookie trails, chat history.
This is the key to being more than a chatbot; this is how to be a Digital Assistant.
Troubleshooting Prep:
Talk to the people who communicate directly with your customers. Hire one of them to be on your bot team.
What they "learn"
What they "learn"
What they "learn"
ONLY What You Teach Them
Supervised VS Unsupervised:
The best way I can illustrate the difference between Supervised and Unsupervised learning is to compare an IVR to a Furby.
It's a weird comparison, I know.
IVR's are supervised. They only learn what you teach them. If they learned how to talk from your customers, they'd swear more.
I know,
ONLY What You Teach Them
Supervised VS Unsupervised:
The best way I can illustrate the difference between Supervised and Unsupervised learning is to compare an IVR to a Furby.
It's a weird comparison, I know.
IVR's are supervised. They only learn what you teach them. If they learned how to talk from your customers, they'd swear more.
I know, because everyone I know had a Furby growing up, and those things could have used some supervision
Memory:
Bots do not have memory. They do not store data... but you can build a version of memory in there. Talk to your engineers about your options for setting and managing states.
Localization Considerations
If you're looking to localize content you'll need to consider your capacity for delivering specific content based on market code (or something similar) or maintaining duplicate content across multiple agents. The latter is technologically easier, but can become a governance nightmare quickly depending on how many locations you're targeting.
.jpg/:/rs=w:1240,h:620,cg:true,m/cr=w:1240,h:620)
Bot Architecture
There's no right way
Of course, there are a ton of wrong ways to architect an experience.
If you have the leeway to fail well, I heartily recommend you experiment with a every terrible way you can think of. In the creative writing world we call these bad pitches. Indulging a bad pitch almost always leads to unusable pages... and at least one nugget of solid gold.
The benefit of doing something in a way you know won't be the "right" way is that the pressure is off. You will be more creative, you will try things and learn things you wouldn't if you were trying to "get it right."
At the end of the day, the right pattern of engagement will become apparent. You'll figure out if you need to use an opt-in model or send content before offering escalation. You'll discover that your use case requires a single bot for a simplified language model or multiple agents working in concert to automate tasks in a hypnotizing dance of hand-offs. But the best way to get it really right, is to get is really wrong, a lot, first.
Building your own architecture
There's a lot of literature out there and a lot of advice. None of it can stand in for cold, hard experience.
Read up on the basics, but prep yourself for the reality that like most things in life, you just have to dive in.
And remember Conversation Design communities make great life guards.
Establishing KPIs
Know the basics
Industry standard metrics include
- Deflection: Users did not require esclation for resolution
- Coverage & Accuracy: Users got relevant answers
- Helpfulness: Users explicity rate content as helpful
Consult your investors
Align with your stakeholders to determine how you'll measure those things
- What they need to see to get backing for further development
- How they'll tell that story, ie reporting strategy
- Who's helping you furnish that data
Data & Reporting
Where you'll get your data
This depends on your particular team and setup; platform, budget, people resources, etc.
Most out-of-the-box chatbot builders have some sort of built-in reporting and/or data analysis tools. They're by and large utterly unhelpful.
Don't get me wrong, I'm not complaining. The engineers refining the NLU and engines powering AI platforms have no shame in their game, the data pieces are garnish on the entree. I don't send my steak back if I'm not happy with the herbs they've dressed it with. I brush them to the side and dig in.
But you will need to either connect a supplementary service like Dashbot or get a BA team to help you get internal reporting set up.
My flow design process
Observe
What do my customers need help with?
- Parse existing bot data/transcripts if I have them
- Examine social media posts, help site data, web traffic
- Mine voicemails, emails, comment cards
Research
What are the ways they ask for that help?
- Where do they ask?
- How do they say it, or say it wrong?
- What are they ultimately trying to do?
Plan
What can I design, that will help them?
- Who will help: Character, voice, & tone
- How they'll help: FAQ, Conversation, API integration, actions vs instructions, etc
- How I'll know they're helping: Defining and aligning on KPIs
Write
How do I communicate, so that they understand the information?
- Make sure the content is scanable
- Never sacrifice clear for concise; assume nothing, ask
- Be mindful of the emotional situation my user is in
Implement
How am I going to get that content in front of them?
- Select the mechanism: Messaging application, Chat window on my site, etc
- Build the conversation: Test responses, coded actions, training, slot filling
- Test, fix bugs, launch
Assess
Is the content helping them?
- My KPI's are already defined, unless I hate myself
- So I measure those
- Identify and diagnose what I got wrong
Revise
Fix whatever I got wrong on my first pass.