We’ve noticed a limitation in how Fin handles instructions when support logic spans multiple categories or requires conditional behavior.
Currently, instructions are expected to fit neatly into isolated sections/intents. However, some support scenarios require layered logic that combines:
- topic classification,
- policy enforcement,
- escalation restrictions,
- conditional responses,
- and fallback behavior.
A good example is our “custom code” support flow.
In this case, we need Fin to:
- recognize requests related to CSS, PHP, JS, SQL, regex, or custom code in general;
- clearly explain that these cases are outside standard support scope according to our policy;
- still attempt to help when possible;
- avoid suggesting escalation to a live agent if Fin cannot solve the issue, because the live support team follows the same policy and cannot provide custom coding assistance either;
- only address escalation if the customer explicitly requests a human agent;
- and in that case:
- remind the customer about the policy,
- explain that the live team has the same limitations,
- and suggest alternative resources such as community help or custom development services.
Right now, Fin tends to:
- split such logic across multiple sections,
- recommend restructuring instructions into separate categories,
- or fall back to default escalation behavior.
This makes it difficult to implement nuanced support policies where:
- the topic,
- escalation behavior,
- and communication strategy
must stay connected within a single instruction flow.