we are recently implementing a chatbot solution for my mother's culinary class business. A valuable use case is making appointments through the bot. Seeing how she's got a lot of available times across 7days of the week, it's pretty unpractical to list out all the slots for the user. So we thought of filtering the selections by weekday/weekend and AM/PM. But this ultimately tempers the user experience by introducing two more stages before knowing when exactly is available, and also doesn't do much as almost everybody wants to book for the weekends.
Are there more user friendly ways to do this? Our bot is currently guided flow based, meaning most of the interactions are done by the user clicking buttons given by the bot.
Thanks a lot! Any help is appreciated!
One small improvement would be not to list options that are already full. So if weekends are already reserved do not offer them, same with AM/PM.
Another improvement would be to create some kind of chat sessions or user database which could track user preferences. So if user scheduled for lets say Monday afternoon in the past, that could be the first option for bot to offer him on next visit.
Just make the chatbot ask the user when he wish to book, then check the availability for time and date. That is the most user-friendly, and what we are used to if we call for book. From that time it should be simpler to offer possible alternative bookings. E.g first available weekend and weekday.
And, yes, use user profiles for rate them according to business policy.
Related
Queues in salesforce can be used to make a bunch of users as owners to a record there by providing record level security to the users in that Queue and on the other hand in team selling also we can make users to view the record (although they are not made as owners) so, my question is what ever we are trying to achieve in team selling can also be achieved by Queues then why do we have these 2 concepts in salesforce
Because they're for completely different things. (That's an admin/architecture question rather than coding, post these on dedicated https://salesforce.stackexchange.com/ for better visibility)
Queues are for "unassigned work". Customer Support Tickets, optionally split to tier 1 and tier 2 (escalations). Leads you purchased from somewhere and now you need to to go through them, nurture them, hopefully convert. Typically you grab a case/lead/whatever from the queue, you claim ownership - it leaves the queue. It may or may not be still visible to your teammates depending on sharing rules... but typically it's "done", taken care of. If the support ticket is too tricky or you go on holidays maybe you'll need to put it back to the queue, it happens. But out of the box - it left the queue = other guys lose visibility of it.
Team selling is different. It's my opportunity, I want to reap the commission from it, I want to keep being the owner. But I recognise I need help to win it. Maybe from marketing guy or another sales rep, maybe I'll agree to 20% cut. Maybe I need in-house developer's help to prototype something that will win this client over.
Maybe we have strict data visibility rules - each country sees only this country's data - but this opportunity happens to be in some border town and I'd like to invite guy from another country's team to help because their warehouse is closer, it'd make more sense to fulfill the order from their side.
You'd make such decisions on case-by-case basis, depending on opportunity. And probably the team would be slightly different each time (or maybe it wouldn't. If you have a dedicated support rep that's doing all this client's cases - he/she could auto cascade to Opportunities and Cases, offer you some unique insight how to wiin the deal).
So it's not exactly same thing as queues where people just pick up next task out of a pile.
I can't quite figure out what is the best approach to tutorials on mobile games. Should the tutorial progress and its features (or some of it) be stored locally on the device or should it all come from the server?
(if someone has a guest account and a facebook account he may face the tutorial twice should it all be stored on the server, mind you)
Thanks in advance
I have a mixture of the two but it gets in the way when I revisit it
The tutorial progression status is the part of the user progress. If you have any information about the user progress store tutorial status there.
The bigger problem though is user identification. Is this user someone who have played the game before or a newcomer? Is this registered user who we think it is or is it a different person? There is no other (feasible) way to confidently answer these questions, you can either make a guess based off the user behavior, or simply ask the user if he have played through the tutorial before. Or more correct if he wants to play it.
Ok, so about a year ago I wrote a web app that helps organize appointments for my dads company. He now "couldn't do business without it". I have decided that I want to build a SAAS subscription model out of it and open it up to the public.
It's currently built on codeigniter and php which I do not think is a good fit for a SAAS version. I am planning on rebuiling it from scratch in laravel 4 and using stripe as a payment gateway.
My concern is how best to handle the database / application structure for more than one client. Currently, it just serves the one business and is very un-abstract and is specific to my dads companies needs. I need it to be able to handle different data depending on what the business who uses it does.
I have looked into multi-tenancy but i'm not sure this is right for this. I am thinking that a 'gmail' style approach would be better. One app / domain that after login the user will see their customised dashboard and only their data.
Before I get stuck in with the coding I need to work out how best to handle multiple 'accounts' on the one database. I do not want to create a table for each user, nor a database for each user.
I guess my question is can anybody point me in the right direction for how best to handle a monthly payment subscription in Laravel? It's not so much the code that I'm stuggling with, rather what exactly I would need to build to handle charging the customer each month and denying them access if billing failed etc.
Thanks
You are in for a lot of reading and a ton of work!
First of all, let's completely ignore the billing aspect of this for now — at the end of the day that portion of the application is really fairly trivial. Take a page out of 37signals Rework (page 93 and 94) and launch your product with a 30 day free trial before you even begin implementing it (you should know how to implement it by then).
Second, why do you think that "gmail" doesn't use multi-tenancy, URI structure tells nothing about the underlying database structure. I'm fairly confident they aren't cloning a database schema for every one of their customers. Therefore you've probably answered your own question — you want to implement multi-tenancy.
You're going to want to abstract your database (and application architecture), and honestly there is no better resource to help you on your way to doing that than Taylor Otwell's (creator of Laravel) book Laravel: From Apprentice To Artisan. His book is not for beginners, and by the time you're done reading it you should probably be able to answer this question for yourself.
You are not going to be creating a table or a database for each user, you aren't even going to be creating one for each organization. Instead you'll be creating abstract database structure in code, which will pull your users data out of the database.
Think about checking for permission to access an organization as another layer of user authentication. On every request you'll be checking to see if that user can access a particular organization. You'll likely also check to ensure that organization is still active (did it expire because they didn't pay?) this will again happen on every request and likely with a filter within laravel.
This really leads to the next very important factor of developing a SaaS application.
I don't know about you, but I'm paranoid, and I couldn't sleep well at night if I wasn't sure that user number 4506 couldn't see the data of an organization that he doesn't belong to. The only really good way to ensure this is through unit testing, which I'd highly suggest learning if you haven't already.
The best way to do this within Laravel 4 is to read Jeffrey Way's book Laravel Testing Decoded. This book is extremely advanced, but still easy to understand if you have a good grasp of the fundamentals.
Last but not least, the number one thing is get involved in the community — the easiest way I'd suggest doing that is idling on the #laravel IRC channel (freenode). Ask some questions, maybe answer some questions, everyone in the channel is very nice and responsive.
You are definitely in for an adventure, don't be afraid to ask questions and make mistakes. Good luck.
As a rough overview, I would have a clients table, and a subscriptions table. Any other data that needs storing such as contacts, or appointments, can be associated using foreign keys to the client table.
In laravel, you can use the ORM to get the currently logged in client, and then through a relationship, fetch appointments and contacts belonging to them.
There are some useful tools for laravel at cartalyst.com, including sentry and sentry-social for user auth, and integrating user accounts with facebook/google/twitter, etc.
Stripe will allow you to configure recurring payments, and will notify you via web hooks each time there is a payment attempt. you can log these in the payments table, and associate them with a user/client. you can use this to keep track of who has paid, and how recently.
Also, bear in mind that you may not want to cancel the account immediately on failed payment.
Stripe will reattempt, and it may be that your best response is after it is two or three days late, or you get an invalid card notification,to get in touch with the client and prompt them to update their payment details.
It may also be an opportunity to check when they last logged in.
If it was over a month ago you can credit them with a free month, and remind them of how much your app can do for them.
By doing this, you may be able to get people to continue using (and paying) for something they had forgotten they had subscribed to.
The form that currently loads during when our beta WinForm application starts up is one that shows a vast array of buttons... "Inventory", "Customers", "Reports", etc. Nothing too exciting.
I usually begin UI by looking at similar software products to see how they get done, but as this is a corporate application, I really can't go downloading other corporate applications.
I'd love to give this form a bit of polish but I'm not really sure where to start. Any suggestions?
EDIT: I am trying to come up with multiple options to present to users, however, I'm drawing blanks as well. I can find a ton of design ideas for the web, but there really doesn't seem to be much for Windows form design.
I have found that given no option, users will have a hard time to say what they want. Once given an option, it's usually easier for them to find things to change. I would suggest making some paper sketches of potential user interfaces for you application. Then sit down with a few users and discuss around them. I would imagine that you would get more concrete ideas from the users that way.
Update
Just a couple of thoughts that may (or may not) help you get forward:
Don't get too hung up on the application being "corporate". Many coprorate applications that I have seen look so boring that I feel sorry for the users that need to see them for a good share of their day.
Look at your own favourite UI's and ask yourself why you like them.
While not getting stuck in the "corporate template", also do not get too creative; the users collected experience comes from other applications and it may be good if they can guess how things work without training.
Don't forget to take in inspiration from web sites that you find appealing and easy to use.
Try to find a logical "flow"; visualize things having the same conceptual functionality in a consistent way; this also helps the user do successful "guesswork".
You might look to other applications that your users are familiar with. Outlook is ubiquitous in my company, and we were able to map our application to its interface relatively easily, so we used that application as a model when developing our UI.
Note that I'm not suggesting Outlook specifically to you, just that you look for UIs that would make your users' learning curve shallower.
The problem here is that you need some good user analysis and I'm guessing you've only done functional analysis.
Because your problem is so abstract, it's hard to give one good example of what you need to do. I'd go to usability.gov and check out the usability methods link, especially card sorting and contextual interviews.
Basically you want to do two things:
1- Discover where your users think how information is grouped on the page: This will help flesh out your functional requirements too. Once you've got information all grouped up, you've basically got your navigation metaphor set up. Also, you can continually do card sorting exercises right down to page and function levels - e.g. you do one card sorting session to understand user needs, then you take one group of cards and ask users to break that down into ranks of importance. Doing so will help you understand what needs to be in dominate areas of the screen and what can be hidden.
2- Understand what tools they already use: what they do and don't like about them. You need to get a list of tools/applications that they use externally and internally. Internally is probably the most important because there is a fair chance that most people in your business will share an experience of using it. External tools however might help give you context into how your users think.
Also, don't be afraid to get pencil and paper and sketch up ideas with users. People generally understand that sketches are a quick and useful way to help with early design work and you can get an immense amount of information out of them with just simple sketches. Yes, even do this if you suck at sketching - chances are it won't matter. In fact, crappy sketches could even work in your favour because then nobody is going to argue if buttons should be blue, red or whatever.
Frankly, a form with a “vast array of buttons” needs more than a little polish. A form dedicated solely to navigation generally means you’re giving your users unnecessary work. Provide a pulldown or sidebar menu on each form for navigating to any form.
The work area of your starting form should provide users with something to actually accomplish their tasks. Among the options are:
A “dashboard” main form, showing summarized information about the users’ work (e.g., list of accounts to review and status of each, number of orders at each stage of processing, To Do schedule). Ideally, users should be able to perform their most common tasks directly in the opening form (e.g., mark each account as “approved” or not). If further information is necessary to complete a task, links navigate to detailed forms filled with the proper query results. At the very least users should be able to assess the status of their work without going any further. Note that different groups of users may need different things on their respective dashboards.
Default form or forms. Users of a corporate application typically have specific assignments, often involving only one to three of all your forms. Users who work with Inventory, for example, may almost never need to look at Customer records, and vice versa. Users also often work on a specific subset of records. Each sales rep, for example may be assigned a small portion of the total number of customers in the database. Divide your users into groups based on the forms and records they usually use. For each user group, start the app by automatically opening the user group’s form(s) populated with the query results of their records. Users should be able to complete most of their work without any further navigation or querying.
If all else fails, open the app to whatever forms and content were last open when the user quit the app. Many corporate users will continue to work tomorrow on the same or similar stuff they’re working on today.
Analyze the tasks of your users to determine which of the above options to use. It is generally not productive to describe each option to the users and ask which they like better.
BTW, “Reports” is probably not a particularly good navigation option. It’s better if you consistently identify things primarily by what they show, rather than how they show it. Users may not know that the information they want to see is in a “report” rather than a form, but they’ll know what content they want to see. Reports on inventory are accessed under Inventory; reports about sales are accessed under Sales.
Have you tried asking your end users what they would like? After all they are the ones that are going to be using the system.
I use components from the company DevExpress. They have some really cool controls (such as the Office 2007 ribbon), form skinning utilities (with a vast amount of different skins), and a load more...
If you want to check it out they have 60 free components - if its corporate though you might have to check the licence but you can get it at... DevExpress 60 Free
I suggest starting with the design principles suggested by Microsoft: Windows User Experience Interaction Guidelines
Some places to get ideas for interaction designs:
Books
About Face 3 - The Essentials of Interaction Design
Don't Make Me Think (this is focused on web design, but many of the principles carry over to Windows design)
Web Sites
Windows User Experience Interaction Guidelines
In addition, many applications have free trial versions that you can download to determine how they handle user interaction. Also, don't discount items on your desktop right now.
Do you have any statistics or insights concerning what the most commonly-used or important functions might be? If so, you could use that to pare down your "vast array of buttons" and highlight only those that are most important.
That's sort of a trivial example, but the underlying point is that your understanding of your audience should inform your design, at least from a functional perspective. You might have past usage statistics, or user stories, or documented workflows, or whatever - even if you're drawing a blank right now, remember that you have to know something about your users, otherwise you wouldn't be able to write software for them.
Building on what they already know can make it easy on your users. Do they live in Outlook? Then you might want to mimic that (as Michael Petrotta suggested). Do they typically do the same thing (within a given role) every time they use the app? Then look for a simple, streamlined interface. Are they power users? Then they'll likely want to be able to tweak and customize the interface. Maybe you even have different menu forms for different user roles.
At this stage, I wouldn't worry about getting it right; just relax and put something out there. It almost doesn't matter what you design, because if you have engaged users and you give them the option, they're going to want to change something (everything?) anyway. ;-)
So, I work in a fairly small IT section. We have a trouble ticketing system that about half of our end users use. Some of my coworkers don't really do much to encourage our end users to use the system we have in place. The end result? Constant interruptions because end users will get us by IM or come to our offices directly for trivial things. This can obviously make it difficult to do a good job of writing code.
Now, I suppose I could just say "hey, would you mind filling out a trouble ticket next time?", but then I'd come off as the bad guy because others won't do that. I also don't want end users to feel that I'm unapproachable. I just want them to understand that there's a proper way to ask for help.
So what's the best thing for me to do in a situation like this?
Make it appealing to do so.
Mention to the user that issues with trouble tickets are viewed by the entire development team and have been found to get fixed significantly faster. Say that anything without a ticket has the potential to get lost in the shuffle. Provide them outward facing links so they can view the progress and developer/support comments on their ticket. Provide email alerts so they feel like they are part of the process and have instant information about their issue.
Make it as frictionless as possible.
Make the user entry part of the system as easy to use and as intuitive as possible. No one likes filling out tickets and I'm certainly not going to jump through any hoops to do so. No logins, no sign-ins, just type out my issue and contact information and go.
Talk with your team.
Ultimately, no amount of hard work on the above systems is going to matter unless your team and you are on the same page. Call for a team meeting and talk with them about the issue. With your boss present, try and put it in terms he can understand. Mention valuable time lost, issues tracking customer problems which aren't in the system, etc, etc.
Sounds like your manager is letting you down by not forcing users to submit a ticket before getting help. The problem starts there and only continues to your co-workers allowing such behavior. We use redmine at work for application support and have made good progress in telling users "submit a ticket and we will look in to it" but it has to be a consistent voice from all people involved.
Use a little psychology on them. For people that don't send in trouble tickets, remind them that 80% of the people in their department use the ticketing system. Even if it is a lie, it will encourage good behavior because of the bandwagon effect. Remember that the more similar the person is to demographic statistic, the more likely it is to influence their behavior. So "your immediate coworkers" will work better than "people in this entire company."
The people that use the ticketing system should get a gold star, no, seriously.
There was a very brief article in February's Harvard Business Review on using social pressure to influence behavior. It discussed some new research but the article didn't include references.
You don't. Users hate that stuff even I do. Instead your policy should be "don't make me think". You have to collect all you need yourself and automatically handle this in an invisible way to your users. After they opt in at install.
You probably won't make much headway unless you convince your coworkers to use the system first. After you've all agreed on the process you want, then you can talk to your users. If everyone on your team is playing by the same rules, you can probably force your users to use the system by having slow turn-around times for issues not entered into the system, or maybe even forget them altogether.
However, even IF you can convince both your coworkers and your users to enter tickets, you'll probably still find the tickets are incomplete/not informative. We've all seen plenty of tickets like "Feature X is broken, fix it plz" and offer no other information. Depending on the number of tickets you get per day, I would probably just bite the bullet and walk over the user and see what their problem is first hand.
We often log a ticket on the user's behalf in this sort of case.
At my old workplace, I was told that nothing could be done without a trouble ticket. When I asked why, I was told that the support team's productivity was measured by using trouble tickets. This had the effect of forcing me to use trouble tickets (since they were required), and giving me the motivation to do so (I didn't want my coworkers to look bad).
At my new workplace, all technical support is subcontracted out. I literally have to call tech support, and they create a ticket on my behalf.
Also - stop encouraging the behavior. Use your IM filtering options to only appear online to the dev team. Don't check your email - or setup filters that filter the high priority stuff (your boss, your dev team) to your inbox, and everything else to a folder you check once a day or once every other day.
Simucal's advice is good. You -will- have to tell them to "file a ticket" instead, at some point. If you ask them after the fact, they aren't going to care because they got what they needed.
A great way to handle this is to have a dedicated person for support. My team did this, and it helped our productivity immensely and eliminated at least 90% of our interruptions.
Barring that (or lieu of), you can each rotate daily as to who gets to handle user requests. This has the upshot of making a trouble ticket more-or-less required; its needed to keep track of what happened in the request when someone else starts working on it. Over time, this also brings more cohesion to your processes: people create small scripts to do common tasks, work that is done is moved into revision control, etc.