Using Fin Tasks, you can give Fin step-by-step instructions for the task you want it to perform. We've provided some best practices and examples when writing these instructions for Fin.
Note: Fin Tasks is currently in a closed beta. If you're interested in getting access, please speak to your Intercom Relationship or Customer Success Manager.
Fin Task best practices
Clearly written instructions can make a major difference in how your Fin Task performs.
General LLM prompting tips
Before diving into the specifics of Fin Tasks, here are some helpful tips that generally apply when working with large language models (LLMs):
A good prompt is imperative and 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.
Task scope and organization
While Fin retains a memory of previous steps and actions taken or data stored, you still need to design tasks with clear boundaries and focused purposes.
When to use a single Fin Task:
All steps are part of a cohesive process with clear progression.
Later steps depend on earlier steps in a logical sequence.
The entire process shares the same decision criteria and outcomes.
When to consider multiple Fin Tasks:
For completely separate business processes
You need to create clear checkpoints in a complex workflow
Different stakeholders or teams own different parts of a process
You want to enable different entry points into a workflow
Task structure
Trigger title and description
Make sure the title is descriptive and not just internal.
Good practice example: Verify and process refunds
Bad practice example: Test123
You should write 3-5 sentences to describe when Fin should trigger this task. Be as specific as possible and make sure to include one or more of the following:
Examples of the types of customer queries that would be answered by this task.
Key phrases customers might use.
Common scenarios in which triggering this task would be appropriate.
Good practice example:
Use this task if a customer asks to cancel an order or asks for a refund on an order. This task will check if the customer is eligible for a cancellation and will proceed with that cancellation, if applicable.
Bad practice example:
Use this task to cancel.
Instructions block
The instruction block follows a structured format composed of the following sections...
1. Instructions:
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.
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 instructions block into smaller steps with more well-defined, constrained logic.
You'll also need to 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 instructions)
If so, where they are available or what their value is, by inserting them directly into the prompt.
If not, where or how they can be gathered (e.g. from the customer)
2. End this task when:
Briefly define what counts as completion of the task. 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.
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:
When you have the value of the refund_outcome output variable with a status of denied, success or escalation, respectively. No other value is valid.
3. Guidance (optional):
Guide how Fin interacts, responds, and behaves during a task by providing clear guidance. Simply describe any specific behaviors you’d like Fin to follow while performing the steps.
Fin Task examples
We have compiled a number of different use case prompts below that can help you shape your Fin Tasks.
Order Refund
Description: 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.
Step 1: Use @get_order_details for order with ID @collected_order_id to retrieve details for that order. Then follow the below logic to determine whether the retrieved order can be refunded:
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. Set @refund_outcome to "denied" and inform the customer of the outcome.
If the order date is less than 30 days older than the present date, proceed to Step 2.
Else, inform the customer you cannot verify whether the order can be refunded and escalate to a human member of the support team. Set @refund_outcome to "escalation" and inform the customer you have taken this action.
Step 2: Use @process_items_refund with the order ID @collected_order_id to process a refund for that order. Then gather the response and:
If the refund has succeeded, inform the customer that the refund was processed successfully. Set @refund_outcome to "success" and inform the customer of the outcome.
Else, if the refund has failed, inform the customer you were not able to process the refund. Set @refund_outcome to "escalation" and inform the customer you have taken this action.
End this task when: You fill in the value of the @refund_outcome variable with a status of either "denied", "success" or "escalation". No other value is valid.
Guidance: Be empathetic when delivering negative news about refund denials. When a refund is successful, be warm and clear about refund processing timelines.
Subscription Cancellation Request
Description: 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.
Step 1: Use @get_subscription_details for the subscription with ID @collected_subscription_id 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.
Set @cancellation_outcome to "denied".
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.
Set @cancellation_outcome to "escalation".
Step 2: Use @cancel_subscription with the subscription ID @collected_subscription_id to process the cancellation. Then gather the response and:
If the cancellation succeeds:
Inform the customer that the subscription was canceled successfully.
Set @cancellation_outcome to "success".
If the cancellation fails:
Inform the customer that you were not able to cancel the subscription and have escalated the issue.
Set @cancellation_outcome to "escalation".
End this task when: You fill in the value of @cancellation_outcome with either "denied", "success", or "escalation". No other value is valid.
Guidance: Be matter-of-fact but empathetic when explaining commitment periods. When successful, confirm clearly what will happen with billing going forward.
Address Change Request
Description: 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.
Step 1: Use @get_customer_profile by providing the ID @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 is "suspected fraud" or "unpaid balance"):
Inform the customer that you cannot proceed with the address change due to account restrictions.
Set @address_change_outcome to "denied".
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.
Set @address_change_outcome to "escalation".
Step 2: Use @validate_address by providing the @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" or "Canada", no other region is supported):
Inform the customer that the address cannot be serviced or is invalid.
Set @address_change_outcome to "denied".
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.
Set @address_change_outcome to "escalation".
Step 3: Use @update_customer_address by providing both @collected_customer_id and @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.
Set @address_change_outcome to "success".
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.
Set @address_change_outcome to "escalation".
End this task when: You fill in the value of the @address_change_outcome variable with a status of either "denied", "success", or "escalation". No other value is valid.
Guidance: Be clear about which regions are supported. When confirming a successful address change, remind the customer this will affect all future shipments.
Loyalty Points Adjustment
Description: 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.
Step 1: Use @get_loyalty_profile with the ID @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.
Set @points_adjustment_outcome to "denied".
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.
Set @points_adjustment_outcome to "escalation".
Step 2: Use @audit_loyalty_activity by providing @collected_loyalty_member_id and @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.
Set @points_adjustment_outcome to "denied".
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.
Set @points_adjustment_outcome to "escalation".
Step 3: Use @adjust_loyalty_points by providing @collected_loyalty_member_id and the @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.
Set @points_adjustment_outcome to "success".
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.
Set @points_adjustment_outcome to "escalation".
End this task when: You assign the @points_adjustment_outcome a final value of "denied", "success", or "escalation". No other values are valid.
Guidance: When a points adjustment is successful, reference the specific transaction that generated the points. Be informative about program policies when denying requests.
Need more help? Get support from our Community Forum
Find answers and get help from Intercom Support and Community Experts