A customer has already enrolled in a course. After they had follow-up inquiries, we replied to their questions and then redirected them back into the enrollment process, starting to ask them what courses they wanted to sign up for again.
Should this logic be written in the guidance? Should it be placed in the role definition or in the conditional constraints?
How should this be adjusted for better results?
Current customer inquiry categories:
- Enrollment (summer or autumn courses)
- Attending trial classes
- Next steps after paying a deposit
- Leave requests (informing about leave policies; the customer doesn’t know where to apply for leave. Previously, we adjusted the system to send instruction images, but now it’s inconsistent—sometimes it sends them, sometimes it doesn’t)
- Course end dates
- Makeup class arrangements
How can we respond appropriately based on these categories without looping back to asking about course enrollment?
Hello! After reviewing your system configuration, we found that the main issue lies in the ambiguity of intent recognition for course enrollment and leave requests in multi-turn dialogue contexts. Our engineers will test several configuration options today and provide you with a recommendation, which we will post below.
Hello! We have identified the issue.
The cause of the problem: The system currently identifies this user’s status as a “new student.” Therefore, when the customer raises any subsequent questions, the system prioritizes the new student enrollment guidance flow and asks again what courses they wish to enroll in.
The reason this status marker was not updated is that previous payment/receipt processes were handled manually, and the system did not synchronize the status from “new student” to “returning student.”
You can try the following two steps as a solution:
Step 1: Add Step 0 Identity Calibration at the beginning of the condition flow. At the start of each new conversation, the system first checks the history to determine if the customer already has enrollment or payment records. If they do but their status is still marked as “new student,” it automatically updates it to “returning student.” This ensures that even if payments were handled manually, the next conversation will be correctly identified.
You can modify and add conditions for identifying “returning students” based on your actual situation.
Step 2: In the payment conversion and group-onboarding skills, add an operation to write/update the status to “returning student” after successful payment verification.
If there are other scenarios where the status needs to be judged as “returning student,” you can also try modifying them using similar operations as described above.
After these changes, when existing returning students ask about leave requests, course completion dates, or makeup class schedules, they will no longer be mistakenly identified as “wanting to enroll in a new course.”
Let’s question this: in condition compliance, if there is only a query action, how does this feature update the student type?
Yes, currently the condition following does not support update actions. You can try adding a new skill to update the current contact’s student type; updates can be performed within the skill.
