> For the complete documentation index, see [llms.txt](https://docs.hablla.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/hablla/end-support-case.md).

# End support case

### Overview

The **Customer Service Completion Component** is a terminal control-state node. Its main function is to formally close an active service ticket in the system and, at the same time, interrupt the execution of the automation flow for the contact in question. It acts as the end of the customer journey, archiving the conversation or interaction and changing the ticket status to resolved or closed.

### Configuration Parameters

The component's configuration is used to categorize ticket closure for auditing and management reporting purposes:

* **Reason:** Dropdown menu used to classify the reason why the service is being closed (e.g., "No response", "Question answered", "Sale completed"). The list of reasons displayed is inherited directly from the closing statuses registered globally in the platform's workspace.<br>

### Visual Builder

The interface of this component is designed to be simple and straightforward, graphically marking the end of a logical branch:

* **Null Output Node (Terminal):** In the visual flow editor, this component acts as an endpoint. It has no connectors or output ports to continue the current flow, since all automation execution for that user is frozen and considered complete after passing through this block.<br>
* **Closure Tag Search:** The dropdown selector offers an internal text search field to quickly find the correct justification in workspaces that have extensive catalogs of closure reasons.<br>

### Special Operators

The logical properties of this component deal with data auditing, session cache cleanup, and performance metric generation (KPIs):

* **Channel Cleanup and Release:** When processing the closure, the system engine clears the temporary variables from the current session and releases the customer's conversation window. This ensures that, if the user sends a new message in the future, the system treats them as a new contact and restarts the automation tree from scratch (instead of trapping them in old histories).<br>
* **Report Metadata Injection (Analytics):** The reason selected in this node is injected directly into the platform's Business Intelligence (BI) database. This makes it possible to measure crucial operational metrics, such as the automatic resolution rate (*First Contact Resolution - FCR*) and the main customer exit bottlenecks.<br>

### 5. Practical Examples

The table below demonstrates classic application scenarios for this component to close service cycles in an organized way:

| **Selected Reason**   | **Node Location in the Flow**                      | **Automation Context**                                                             | **Practical Use Case**                                                                             |
| --------------------- | -------------------------------------------------- | ---------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- |
| **No response**       | Connected after a wait or inactivity node.         | The customer stopped responding to the chatbot for more than 6 hours.              | Close the ticket due to inactivity so as not to pollute the company's service time metrics.        |
| **Question Answered** | Connected in the "Successful Self-Service" branch. | The customer consulted the Knowledge Base and selected "Yes, I solved my problem." | End the flow and the ticket, ensuring the request was resolved via artificial intelligence or FAQ. |
| **Disqualified Lead** | Connected after the profile filtering block.       | The lead provided information that does not align with the company's sales policy. | End the triage flow immediately, archiving the contact without sending it to the human team.       |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.hablla.com/hablla-docs-en/automation-flows/all-components/hablla/end-support-case.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.