Using Fin Tasks, you can give Fin custom instructions on the task you want it to perform. We've prepared some good examples which you can check out below:
You can template the instructions with data, instruct Fin to run actions, store action response data, reply to users, and reference content from your knowledge base (coming soon).
Task tips best practices
A good prompt can make a major difference in how your Fin Task performs.
General LLM prompting tips
Before we dive into the specifics of tips and how to formulate best Fin Tasks, here are some helpful tips that generally apply when working with large language models (LLMs).
A good prompt is imperative, instructive. Start sentences with a verb and avoid passive voice.
Leave no room for ambiguity: detailed instruction is better than brief.
For some additional reading, see the introduction topics here.
Fin Task tips
Task structure
It is very important to make sure that each “Give Fin a Task" block should perform one task and one task only. If you need to do a lot, it may be better to split the prompt into more Fin Tasks.
One clear and significant benefit from splitting your prompt into multiple Fin Tasks is the ability to specify output variables and collect their values as mandatory requirements for finishing a task. These can then be used in a later Fin Task, allowing for greater control over whether and how they get used in this task.
Let’s imagine we have a task where we want to fetch all orders on a specific date. We could:
Tell Fin to collect the date and filter all orders from that customer based on that date in a single Fin task block.
Or we could split this process into two blocks, one for date collection and one for order filtering, and sequence them together.
For example, a task that handles both collecting date and filtering in one task would look something like this:
While the task that has 2 separate blocks, one for date collection and one for order processing might look something like this:
The two solutions are very similar, but with two important distinctions:
The one-block solution limits control over whether Fin collects the date value and how effectively it is used in the prompt. Even if collected, we can't explicitly reference it in the 'if' condition, relying instead on Fin to make the connection.
The two-block solution prevents backtracking if the process has moved to the second block, which (by design) lacks access to the first block’s logic and actions.
While this is a simple example where it might be fine to use just a single block, it clearly shows the benefits of using more but simpler tasks to achieve a greater level of control over the process and greater assurances over the reliability of execution.
Task prompt structure
In this section we provide what we believe to be a useful mental model to have when building a Fin task prompt.
Tasks serve as a guide to Fin rather than a strict execution plan that must be followed. Fin will choose the best step depending on what is happening.
Task Goal and Guidance
Define the overarching purpose of the task, i.e. what the task aims to accomplish. This goal sets general behaviours you want Fin to display that are applicable to many or all steps of the task execution.
As an example, the goal around a refund task could be set as follows:
The goal of this task is to determine if a refund request made by a customer is valid, and if so, process it. By following the below instructions, you will be able to verify and process a customer’s refund request for orders made with Company X
Required Attributes
Identify the input values needed to perform the task. Explicitly state in the prompt:
What these attributes are and what they can be used for, and how these attributes relate to the task’s broader context.
Whether these attributes are guaranteed to be available (e.g. from a previous step in the task)
If so, where they are available or what their value is, by inserting them directly into the prompt as shown here <link to the other article>
If not, where or how they can be gathered (e.g. from the user)
If we continue with our previous example, attributes might include a purchase date, a transaction ID, or the reason for the customer requesting a refund.
Execution Plan
This is a clear, logically-complete, step-by-step plan that Fin should follow. Make sure to cover all the decision rules that are necessary for Fin to perform the task, otherwise Fin might hallucinate those rules.
The best and easiest way to formulate these is to follow an “if + else” logic. This logic guarantees you will always be able to make a decision at any stage and either make progress towards a solution or have a way out of the process if you are stuck. For our example, this would look like:
1. If you can determine the order date and it is less than 30 days ago, issue a refund.
2. If you can determine the order date but it is above 30 days ago, tell the customer Company X’s policy does not allow for refunds on purchases more than 30 days into the past.
3. Else, tell the customer you will escalate to a human member of the support team, and execute the escalation by doing… (this example assumes escalation logic has been built into the Fin task)
If the logic and information Fin needs to access is too open-ended, you should consider whether you can break down the Fin Task block into smaller blocks with more well-defined, constrained logic that can go in the prompt.
Completion Definition
Clearly define what counts as completion of the task. Make sure the task description clearly and explicitly communicates when the overall task is complete.Specify the conditions under which the task can be considered to be completed, regardless of it producing a positive or negative outcome for the customer.
An example of this would be:
You will have completed this task when, following the logic specified above, you have determined the current step to be your last step, either because you have decided that the refund cannot be processed, because you have successfully processed the refund, or because you have escalated the refund request to a human member of the support team.
If possible, you should also include information about any task attributes/attributes required by the task. If the output variable you are trying to fill in is e.g. refund_outcome, add:
Mark the task as complete when you have enough information to fill in the value of the refund_outcome
output variable with a status of denied
, success
or escalation
, respectively. No other value is valid.
Fin Task library
We have compiled a number of different use case prompts below that can help you shape your Fin Tasks.
All of them should be preceded by a “Give Fin a task” block (or more than one, depending on the use case) that collects some data from the user such as order or member ID or a reason for refund/cancellation.
Order refund
The goal of this task is to determine if a refund request made by a customer is valid, and if so, process it. By following the below instructions, you will be able to verify and process a customer’s refund request for orders made with Company X.
Then you will think step-by-step to strictly complete the below execution plan:
Step 1:
Use action get_order_details for order with ID value_of_collected_order_id_attribute
to retrieve details for that order. Then follow the below logic to determine whether the retrieved order can be refunded:
a) If the order date is more than 30 days older than the present date, inform the customer you cannot offer a refund because the order was initially made more than 30 days ago. You can do this by marking the task as completed with refund_outcome set to denied and informing the customer of the outcome. This is your last step.
b) If the order date is less than 30 days older than the present date, proceed to Step 2.
c) Else, you should inform the customer you cannot verify whether the order can be refunded and escalate to a human member of the support team. You can do this by marking the task as completed with refund_outcome
set to escalation and informing the customer you have taken this action. This is your last step.
Step 2:
Use action process_items_refund
and provide it with the order ID value_of_collected_order_id_attribute
to process a refund for that order. Then gather the response and:
a) If the refund has succeeded, inform the customer that the refund was processed successfully. You can do this by marking the task as completed with refund_outcome
set to success and informing the customer of the outcome. This is your last step.
b) Else, if the refund has failed, inform the customer you were not able to process the refund. You can do this by marking the task as completed with refund_outcome
set to escalation and informing the customer you have taken this action. This is your last step.
You will have completed this task when, following the logic specified above, you have determined the current step to be your last step, either because you have decided that the refund cannot be processed, because you have successfully processed the refund, or because you have escalated the refund request to a human member of the support team.
Mark the task as complete when you have enough information to fill in the value of the refund_outcome
output variable with a status of either denied
, success
or escalation
, respectively. No other value is valid.
Subscription cancellation request
The goal of this task is to determine if a subscription cancellation request made by a customer is valid, and if so, to process it. By following the instructions below, you will be able to verify and cancel a customer’s subscription for Company X.
Then you will think step-by-step to strictly complete the below execution plan:
Step 1:
Use action get_subscription_details
for the subscription with ID value_of_collected_subscription_id_attribute
to retrieve details for that subscription. Then follow the below logic to determine whether the retrieved subscription can be canceled:
If the subscription is still in its minimum commitment period (a 12-month term that has not yet elapsed):
Inform the customer that you cannot cancel the subscription at this time because the subscription is within its commitment period.
Mark the task as completed with cancellation_outcome set to denied.
This is your last step.
If the subscription is eligible for cancellation (it is a month-to-month plan or the commitment period is over):
Proceed to Step 2.
Otherwise, if you cannot determine from the subscription details whether it can be canceled:
Inform the customer you cannot verify the subscription’s cancellation eligibility and escalate to a human member of the support team.
Mark the task as completed with cancellation_outcome set to escalation.
This is your last step.
Step 2:
Use action cancel_subscription
and provide it with the subscription ID value_of_collected_subscription_id_attribute
to process the cancellation. Then gather the response and:
If the cancellation succeeds:
Inform the customer that the subscription was canceled successfully.
Mark the task as completed with
cancellation_outcome
set to success.This is your last step.
If the cancellation fails:
Inform the customer that you were not able to cancel the subscription and have escalated the issue.
Mark the task as completed with
cancellation_outcome
set to escalation.This is your last step.
You will have completed this task when, following the logic specified above, you have determined the current step to be your last step - either by deciding that the subscription cannot be canceled, successfully canceling it, or escalating to a human member of the support team. Mark the task as complete when you have enough information to fill in the value of cancellation_outcome with either denied, success, or escalation. No other value is valid.
Address change request
The goal of this task is to determine if a requested shipping address update for a customer is valid, and if so, to process it. By following the instructions below, you will verify and update the shipping address in Company X’s system.
Then you will think step-by-step to strictly complete the below execution plan:
Step 1:
Use action get_customer_profile
by providing the ID value_of_collected_customer_id
to retrieve the customer’s current account status. Then follow the logic below:
If the customer’s account is locked or flagged (their
account_status
issuspected fraud
orunpaid balance
):Inform the customer that you cannot proceed with the address change due to account restrictions.
Mark the task as completed with
address_change_outcome
set to denied.This is your last step.
If the customer’s account is active and eligible for updates:
Proceed to Step 2.
Otherwise, if the system is unable to determine the account status or if there is insufficient information:
Inform the customer you cannot verify whether the address can be updated and escalate to a human support agent.
Mark the task as completed with
address_change_outcome
set to escalation.This is your last step.
Step 2:
Use action validate_address
by providing the value_of_collected_new_address
to verify its authenticity and deliverability. Then follow the logic below:
If the new address is not recognized or is outside of Company X’s serviceable regions (address value can only be
United States
,European Union
orCanada
, not other region is supported):Inform the customer that the address cannot be serviced or is invalid.
Mark the task as completed with
address_change_outcome
set to denied.This is your last step.
If the address is recognized and deliverable:
Proceed to Step 3.
If the address validation result is inconclusive or cannot be determined by the system:
Inform the customer you are unable to verify the address at this time and have escalated the request.
Mark the task as completed with
address_change_outcome
set to escalation.This is your last step.
Step 3:
Use action update_customer_address
by providing both value_of_collected_customer_id
and value_of_collected_new_address
to finalize the address update. Then follow the logic below:
If the address update is successful:
Inform the customer that the address has been updated successfully.
Mark the task as completed with
address_change_outcome
set to success.This is your last step.
If the address update fails for any reason (a system error or conflicting records):
Inform the customer you have escalated the issue to a human support agent.
Mark the task as completed with
address_change_outcome
set to escalation.This is your last step.
You will have completed this task when, following the logic specified above, you have determined the current step to be your last step - either because the address request was denied, successfully updated, or escalated to a human support agent. Mark the task as complete when you have enough information to fill in the value of the address_change_outcome
output variable with a status of either denied, success, or escalation. No other value is valid.
Loyalty points adjustment
The goal of this task is to determine if a customer’s request for a loyalty points adjustment is valid, and if so, to carry out that adjustment. By following these instructions, you will review the customer’s loyalty account status, validate the request, and then adjust the points accordingly in Company X’s system.
After gathering these details, think step-by-step to strictly complete the execution plan below:
Step 1:
<Use action get_loyalty_profile> with the ID <value_of_collected_loyalty_member_id> to retrieve the member’s account status. Then follow the logic:
If the loyalty account is inactive, suspended, or flagged for suspicious activity:
Inform the customer that their account is not eligible for a points adjustment at this time.
Mark the task as completed with points_adjustment_outcome set to denied.
This is your last step.
If the account is in good standing:
Proceed to Step 2.
Otherwise, if the system cannot determine the account status:
Inform the customer you cannot verify their account and will escalate this matter to a support specialist.
Mark the task as completed with points_adjustment_outcome set to escalation.
This is your last step.
Step 2:
Use action audit_loyalty_activity
by providing value_of_collected_loyalty_member_id
and value_of_collected_points_adjustment_request
to review recent loyalty transactions and see if the request is justified. Then:
If the requested adjustment pertains to a transaction outside the claim window (claim date is more than 90 days ago):
Inform the customer that the request cannot be granted due to program policies.
Mark the task as completed with
points_adjustment_outcome
set to denied.This is your last step.
If the request is valid (for example, points were missed from a recent eligible purchase):
Proceed to Step 3.
If the audit returns inconclusive results (no matching transaction found or partial data only):
Inform the customer that further investigation is required, and you are escalating the matter to a human agent.
Mark the task as completed with
points_adjustment_outcome
set to escalation.This is your last step.
Step 3:
Use action adjust_loyalty_points
by providing value_of_collected_loyalty_member_id
and the value_of_collected_points_adjustment_request
amount to finalize the points adjustment. Then:
If the points adjustment is processed successfully:
Inform the customer that their loyalty balance has been updated.
Mark the task as completed with
points_adjustment_outcome
set to success.This is your last step.
If the adjustment fails due to a system error or conflicting records:
Inform the customer that you were unable to complete the request and have escalated it for manual review.
Mark the task as completed with
points_adjustment_outcome
set to escalation.This is your last step.
You will have completed this task when the logic above leads you to your final step - either denying the points adjustment, successfully applying it, or escalating to a human agent. Mark the task as complete when you have enough information to assign the points_adjustment_outcome
a final value of denied, success, or escalation. No other values are valid.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts