You’re ready, well, your business or brand is ready to take the leap and integrate modern Chatbot software to optimize customer service operations. But before you approach a company like Virtus Ventures to design it, you want some basic product requirements assembled.
No problem. Let’s walk through the process of putting together a PRD to help iron out your vision. You know, get some of those ducks in row. First, a simple definition.
What’s a PRD?
A PRD, or Product Requirements Document, is a combination of a Business Requirements Document (BRD) and a Systems Requirements Document (SRD). Don’t be deceived by those techy-sounding titles, because what we’re really talking about is detailing how something works and what’s required.
Note: This guide is for someone who’s never created a PRD before, so no experience or programming knowledge needed. We’re not getting into technical stuff, and if you’re interested check out my article, “Improve Customer Service Through Bot Technology?” to get a broad breakdown of the subject.
Do I Absolutely Need a PRD?
No, you don’t NEED a PRD. Virtus and most other serious tech companies like us can put one together with you but there are four solid reasons to go through the exercise:
- Gain a better understanding of your business itself, especially concerning customer service – how it’s working, where it falls short, etc.
- Really nail down your goals when it comes to your chatbot before getting technical.
- Dramatically increase the chances a serious designer, developer, or firm will work with you and help bring your vision to life (which includes angel investors, venture capitalists, startup funds, and so forth).
- Streamline the development time and costs which will inevitably make everyone in your company mucho happy.
Think of it as a quasi-business plan for a single software product. As such, before you begin going through each section, and before you start trying to put together an Overview, there are 5 key components to consider.
Let’s briefly go through them and then we’ll move on to the core template.
Who: This Chatbot Software will be for people who reach out to your company through customer service channels.
Why: This chatbot is more directly for your business than customers – lowering overhead, increasing efficiency, and freeing up resources which can be leveraged perhaps through further digitization, better products, etc.
When: There are tons of variables here, but when would you like to see your new chatbot technology go live? In general, it takes Virtus roughly 2 months to plan, code, and integrate (with your PRD in hand you can cut that time in half!).
What: How do you see it working? Again, will your chatbot interact with people through phone only? Email? Website chat? App? Social media? All of the above simultaneously?
How: First, we use existing cutting edge chatbot technology as a base then customize according to your business needs/systems.
The Current State of Chatbot Tech
Can Virtus and companies like us innovate, given the time, resources and budget? Sure!
Chances are you’re not interested in funding an expansive R&D project into machine/deep learning and A.I. though. You’d just like your company to get aboard the chatbot-boat and modernize.
So where’s current baseline chatbot tech (note that this article is originally being published in late 2017)? If you’re like most, your bot will be able to:
- Interact (written/verbal) with humans who approach with simple specific goals in mind.
- Give folks scripted information about your product, services, brand, etc.
- Answer common FAQs with specific, or “canned” answers.
- Deliver company updates – stocks, order/ticket notifications, recent news, etc.
Down the road your brand could sport highly-intelligent conversational UI or software but we’re not quite there yet. You can integrate simple machine learning and dedicate resources to building your chatbot over time though (tons of Bot-Funding going on).
Right now, customer service issues need to be more on the simple, streamlineable, and specific side where real humans aren’t required. Or, where humans aren’t always required and bots can supplement.
Presently, your bot’s personality will be somewhat bot-like. Meaning, it won’t be able to understand or replicate the many nuances of verbal language – complex humor, sarcasm, wit, slang, and so forth. That’s not to say it won’t be conversational!
Basic Chatbot PRD Outline
Fair enough? So far so good. Now we’re going to go through the outline, or template step-by-step. Here’s the sections we’ll cover:
- Overview
- Target Users
- User Issues Solved
- User Stories (Functionality)
- Release or “Going Live” Criteria
Overview
The overview of your PRD is like a pitch – a short and concise description of the chatbot you’re after and how it’ll function. You can make it as long winded as you’d like, but less is more; a few hundred words maybe to start. Here’s an example off the top of my head:
“A good portion of the customer service questions and queries my business receives via phone, email, and chat can be handled without human intervention, for example giving people directions, verifying or changing service/product specifications, handling returns/exchanges, or delivering account information.”
“Through a chatbot, we can dramatically speed up our customer service processes while improving the overall experience – less friction and frustration. Personalized automation will also save my company boatloads of cash annually through reduced labor costs and better customer management, organization, reporting, and communication.”
Target Users of Chatbot
In this section the focus is on users, or the people primarily responsible for interacting with the chatbot. And yes, you need to get somewhat specific here. Break things down by channel and include user information for each.
- Who typically uses each channel? Include critical demographics.
- What are the big differences between them?
- What are the most common queries or customer needs?
- How much can be safely automated, or allocated to a bot?
- How much of the filtering process can your bot handle?
What I mean by filtering is helping calls that require a human get to the right departments faster. Maybe a huge service will be your bot initially touching base with customers, ascertaining their needs, and getting them on the phone with someone who can help if they can’t.
User Issues & Resolutions
This section is all about giving the designer an idea of how you envision the bot solving customer needs across applicable channels. In the examples below I’ve touched on some scenarios concerning email, website chat, and phone.
- Need: User has a quick question concerning return policy and engaged website chat function rather than trying to locate the information themselves.
- Resolution: Chatbot instantly replies in a conversational way, maybe with an emoji or two, and asks what the problem is. Through simply keyword functions ascertains the issue, and provides a link directly to company’s return policy.
- Need: User can’t locate automated purchase email-receipt and has emailed the company asking for another copy to be sent to the email associated with their account.
- Resolution: Bot scans email for issues it can solve, ascertains that it can solve this query, sends another purchase receipt to the account email, confirms, and asks if there’s anything else it can help with.
- Need: User has questions regarding product specifications. They tried Google for a couple minutes, but decided to call the company instead.
- Resolution: Bot begins ascertaining what the caller would like, and understands they want product specifications. It identifies purchase order and specifications the user is after and supplies the answers in a simple conversational way. Then passes caller along to human agent for more complex questions regarding individual specifications.
- Need: User wants to cancel their account, but would rather “speak to someone” than go through the process via company website. So, they reach out to admin of the company Facebook page via Messenger.
- Resolution: Bot quickly ascertains the user wants to cancel their account, let’s them know it can only be done via the website, and sends them a direct link to the page where this process begins.
Just to give you an idea. If you have access to all the user-behavior your company’s collecting, this part should be pretty straightforward. Then of course there’s that diligent history of queries your current customer service staff has been addressing and all manner of customer data to help.
User Stories
In essence, all you’re concerned with in this section is giving designers an idea of functionality. It’s not about design, but to give them another look at what kind of interactions will take place.
You can add as many of these little stories as you’d like, within the bounds of your budget, but here are the basics in the example we’ve been building in this article:
- As a user, I can interact with the bot via the website “Help Desk” chat function.
- As a user, I can interact with the bot via the customer service phone number.
- As a customer service agent, I can create a report that shows “X” for weekly reports.
- As a user, I can interact with the bot via email.
- As a user, I can interact with the bot through website chat after setting up an account.
- As a customer service agent, I can add additional questions the bot can answer.
- As a business owner…
By making these story-based, it helps people in charge of design frame their mindset for each particular user. We then use them to create a variety of flowcharts which turns into your specs document and so on. From there we would create wireframes, or if it can use a current template that we already have we’d start coding.
Technical Process & Specs
Originally I intended on adding this section but quickly realized that non-programmers and coders aren’t going to need to be too concerned here. This is a section best filled out with professionals that understand this part. If, however, you do have the experience or knowledge feel free to add core processes and specs.
Release or “Going Live” Criteria
What are the minimum requirements your chatbot software needs to go live? No one’s expecting you to know this on a programming level, or feasibility, but start giving it consideration. Not just in terms of rough project timelines, but along these as well:
- Performance
- Scalability
- Reliability
- Usability
- Supportability
Of course your development team will handle testing usability, quality assurance, tracking data and reporting, but another important step is working with them to figure out what the minimum required features are and how to prioritize them.
Which are must-haves and which are the nice-to-haves for both engineering-driven and customer-driven requirements?
Don’t worry, when you meet with your development team they’ll be able to spell out features in dollars and cents. You’ll know what to budget for your “Going Live” chatbot software, and what costs are associated with the full range of its capabilities/functions.
Wrapping Up
The first time you create a serious PRD it can take some elbow grease, but it’s worth the effort. As I mentioned earlier, if you contact Virtus Ventures to handle the creation and implementation of your customer service chatbot software, a relatively decent PRD can cut overall project time in half!
Although as you can see, the process is going to be enlightening as well and should cast light upon your current customer service operations. Thanks for your time, and do let us know if we can help. Cheers!
The post How to Draft a Basic PRD for Customer Service Chatbot Software appeared first on Virtus Ventures.
