# Guiding Users

## Implicit Confirmation

Implicit confirmation involves repeating details back to the user to reassure them that they were understood correctly. This also gives the user a chance to intervene if your assistant misunderstood.

**Example:**  
**User:** Can I get a large hawaiian and bbq pizza  
**Assistant:** Sure, that's one large hawaiian and one regular bbq pizza.

**User:** Anything else?  
**Assistant:** No they should both be large!

## Explicit Confirmation

Explicit confirmation means asking the user to clarify how you should help them. An important thing to remember about AI assistants is that **the user is never wrong**. When a user tells you something like I just moved, they are being perfectly clear, even if your assistant is not sure how to help them.

**Example:**  
**User:** I just moved  
**Assistant:** I'm not sure I understood you correctly. Do you mean ...  
**User:** I want to cancel my contract  
**Assistant:** I want to update my personal details

You can configure the `TwoStageFallbackPolicy` to ask your user to clarify, and present them with quick replies for the most likely intents. To do this, configure the policy as in this example:

```yaml
policies:
- name: TwoStageFallbackPolicy
  nlu_threshold: 0.3
  core_threshold: 0.3
  fallback_core_action_name: "action_default_fallback"
  fallback_nlu_action_name: "action_default_fallback"
  deny_suggestion_intent_name: "out_of_scope"
...
```

## Explaining Possibilities

AI assistants are always limited to helping users with a specific set of tasks, and should be able to explain to a user what they can do. That includes coherently responding to requests that are out of scope.

**Example:**  
**User:** What can you do?  
**Assistant:** I can help you update your personal details, change your plan, and answer any questions you have about our products.

**User:** Can you get me a pizza?  
**Assistant:** I'm afraid I can't help with that.

To gracefully handle out-of-scope requests, you might use stories such as:

```yaml
## user asks whats possible
* ask_whatspossible
  - utter_explain_whatspossible

## user asks for something out of scope
* out_of_scope
  - utter_cannot_help
  - utter_explain_whatspossible
```

## Collecting User Feedback

Asking for feedback is one of the best tools you have to understand your users and determine whether you solved their problem! Storing this feedback is a powerful way to figure out how you can improve your assistant.

**Example:**  
**User:** Was that helpful?  
**Assistant:** no.

**User:** Thanks. Why wasnt I able to help?  
**Assistant:** you didn't understand me correctly  
**Assistant:** you understood me, but your answers weren't very helpful.

To collect feedback, define a custom form action:

```python
from rasa_sdk.action import FormAction

class FeedbackForm(FormAction):

def name(self):
        return "feedback_form"

@staticmethod
    def required_slots(tracker):
        return ["feedback", "negative_feedback_reason"]
```

Add the form and slots to your domain:

```yaml
forms:
  - feedback_form
slots:
  feedback:
    type: bool
  feedback_reason:
    type: text
  requested_slot:
    type: text
```

And ensure the `FormPolicy` is present in your configuration file:

```yaml
policies:
  - FormPolicy
  ...
```

## Handing off to a Human

Users will be very frustrated if your assistant cannot help them and there is no way to reroute the conversation to a human agent. There should always be a way to break out of a conversation!

**Example:**  
**User:** let me speak to a human  
**Assistant:** let me put you in touch with someone.

There are various reasons why you might trigger a human handoff:
- the user asks to speak to a human
- the assistant is struggling to understand the user
- the assistant understands what the user wants, but a human is required to resolve the issue.

For instance, you can handle a direct request with the mapping policy:

```yaml
intents:
  - request_human: {"triggers": "action_human_handoff"}
```