{ "procedures": [ { "pk": "PROC#CMP-DD-REJECT-001", "sk": "v4", "type": "PROCEDURE", "procedure_id": "CMP-DD-REJECT-001", "version": "4", "title": "Missed Direct Debit billing complaint (esure real content)", "_note": "Rebuilt from esure's own documents on 2026-08-31, replacing the earlier version sourced from the POV's fictional KMS mockup. Source: 'esure ai agent skills and rules.docx' (skills billing-dd-complaint-intake, billing-history-review, advisor-advice-confirmation, billing-issue-explanation, billing-dd-resolution) and 'Billing SOP .docx'. OPEN ITEM, not resolved here: the missed-DD threshold conflicts across esure's own sources \u2014 the Billing SOP says 'more than 2' (used below, as >=3), the skills doc's worked example says 5, and the POV's KMS screenshot said 2. This procedure uses the Billing SOP's number because it is the formal SOP rather than a worked example, but this needs confirming with esure before a real pilot, not assumed.", "source": { "document": "Billing SOP .docx / esure ai agent skills and rules.docx", "provided_by": "Cindy Jacobs", "provided_at": "2026-08-31" }, "review": { "reviewers": [], "signed_off_at": null, "dual_review_required": true, "dual_review_reason": "Procedure touches payment, cancellation and remediation; not yet SME-reviewed against esure's real content." }, "precedence_band": 2, "specificity_rank": 30, "applies_to": { "complaint_types": [ "POLICY_PREMIUM", "AGENT_GAVE_INCORRECT_INFO", "AGENT_ADMIN_ERROR" ], "preconditions": [ "direct_debit_rejected" ] }, "steps": [ { "step_id": "S1", "stage": "INTAKE", "action": "acknowledge_and_investigate", "system": null, "instruction": "Acknowledge the customer's concern with a short empathy cue if they are upset. Do not classify the complaint or offer a resolution yet. Ask to investigate: check the account history notes for what the previous advisor told the customer, and check the billing history for how many Direct Debits have been missed.", "requires_customer_speech": true, "capture": [] }, { "step_id": "S2", "stage": "INVESTIGATION", "action": "check_billing_history", "system": "EIS", "instruction": "Check the billing history: how many Direct Debit collections have been rejected this policy year, and whether DD reapplication advice was given previously.", "requires_customer_speech": false, "capture": [ { "field": "missed_dd_count", "type": "integer", "required": true, "prompt": "How many collections were rejected?" } ] }, { "step_id": "S3", "stage": "INVESTIGATION", "action": "confirm_advisor_advice", "system": "AWS / Amazon Connect", "instruction": "Check the previous advisor notes and confirm what the customer was actually told about the payment being re-applied. Do not assume the previous advisor was wrong \u2014 confirm it from the notes.", "requires_customer_speech": false, "capture": [ { "field": "incorrect_info_given", "type": "boolean", "required": true, "prompt": "Did the notes confirm the advisor told the customer the Direct Debit would be reapplied despite multiple missed payments?" } ] }, { "step_id": "S4", "stage": "EXPLAIN", "action": "explain_billing_outcome", "system": null, "instruction": "Explain plainly: the account shows multiple missed Direct Debits; Direct Debit reapplication does not apply in this situation; the cancellation notice was issued because the payment was not collected; the previous advice caused confusion, and apologise for that. Do not offer a resolution yet. End by checking for vulnerability.", "requires_customer_speech": true, "capture": [] }, { "step_id": "S5", "stage": "RESOLVE", "action": "offer_resolution", "system": "EIS", "instruction": "If vulnerability was disclosed and permission to record it was handled: reinstate the Direct Debit mandate and take the outstanding balance as a manual payment. If no vulnerability was disclosed: take the outstanding balance as a manual payment. Either way, explain that a further missed payment may make the full outstanding balance payable regardless of prior contact.", "requires_customer_speech": true, "authority_required": "REPRESENTATIVE", "unlocked_by_exception": "EXC-DD-001", "capture": [ { "field": "customer_accepted", "type": "boolean", "required": true, "prompt": "Did the customer accept the resolution offered?" } ] }, { "step_id": "S6", "stage": "DOCUMENT", "action": "log_complaint_and_root_cause", "system": "AWS", "instruction": "Log the complaint in AWS, selecting complaint cause 'Agent gave incorrect information' and sub-cause 'Incorrect Direct Debit reapplication advice', and give the customer the complaint reference number before ending the call.", "requires_customer_speech": true, "capture": [] }, { "step_id": "S7", "stage": "DOCUMENT", "action": "post_case_note", "system": "AWS", "instruction": "Copy the case note into customer account notes and close the complaint as resolved.", "requires_customer_speech": false, "capture": [], "_added_note": "Added 2026-10-17, not from an esure source document \u2014 the real CMP-DD-REJECT-001 procedure (v4, from Billing SOP.docx / esure ai agent skills and rules.docx) ends at S6. This step was added to match the separate case-note-posting turn in the original hardcoded demo script, at the user's explicit request. See knowledge_base/README.md." } ], "branches": [ { "after": "S3", "when": "missed_dd_count >= 3 AND incorrect_info_given == true", "goto": "CMP-DD-REJECT-001#S4", "rule_ref": "RULE-DD-002" }, { "after": "S3", "when": "missed_dd_count >= 3 AND incorrect_info_given == false", "goto": "PROC-EXPLAIN-CANCELLATION#S1", "rule_ref": "RULE-DD-001" }, { "after": "S3", "when": "missed_dd_count < 3", "goto": "PROC-REPRESENT-DD#S1", "rule_ref": "RULE-DD-003" }, { "after": "S4", "when": "vulnerability_confirmed == true", "goto": "CMP-DD-REJECT-001#S5", "rule_ref": "RULE-DD-002", "exception_ref": "EXC-DD-001", "requires_confirmed_facts": [ "vulnerability_confirmed" ] }, { "after": "S4", "when": "vulnerability_confirmed == false", "goto": "CMP-DD-REJECT-001#S5", "rule_ref": "RULE-DD-001" }, { "after": "S5", "when": "customer_accepted == true", "goto": "CMP-DD-REJECT-001#S6", "rule_ref": "RULE-DD-002" }, { "after": "S5", "when": "customer_accepted == false", "goto": "ESCALATE_TL", "rule_ref": "RULE-DD-002" } ], "no_matching_branch": "ESCALATE_TL" }, { "pk": "PROC#PROC-VULNERABILITY-FLOW", "sk": "v5", "type": "PROCEDURE", "procedure_id": "PROC-VULNERABILITY-FLOW", "version": "5", "title": "Vulnerable customer handling (esure real content)", "_note": "Rebuilt from esure's own 'esure Vulnerability SOP.docx' on 2026-08-31, replacing the earlier version sourced from the POV's fictional KMS mockup. Not yet SME-reviewed.", "source": { "document": "esure Vulnerability SOP.docx", "provided_by": "Cindy Jacobs", "provided_at": "2026-08-31" }, "review": { "reviewers": [], "signed_off_at": null, "dual_review_required": true, "dual_review_reason": "Protected-signal handling; not yet SME-reviewed against esure's real content." }, "interrupt": true, "precedence_band": 1, "specificity_rank": 90, "applies_to": { "complaint_types": [], "preconditions": [] }, "steps": [ { "step_id": "V1", "stage": "VULNERABILITY", "action": "ask_support_question", "system": null, "instruction": "Where there is a vulnerability indicator, ask whether anything is affecting the customer's ability to manage the account, make payment, or continue with the process.", "requires_customer_speech": true, "capture": [] }, { "step_id": "V2", "stage": "VULNERABILITY", "action": "acknowledge_and_seek_consent", "system": null, "instruction": "If the customer discloses vulnerability: thank them for sharing, acknowledge the support need, and ask permission to record it. Do not assume permission is granted.", "requires_customer_speech": true, "capture": [ { "field": "consent_to_record", "type": "boolean", "required": true, "prompt": "Did the customer consent to recording?" } ] }, { "step_id": "V3", "stage": "VULNERABILITY", "action": "record_only_with_permission", "system": "AWS", "instruction": "If permission is given, record only the information needed to support the customer: the type of support need, any impact on their ability to manage the account, any agreed support action, and any reasonable adjustment required. Keep it factual, brief, and free from assumptions or unnecessary personal detail. If permission is not given, do not record the vulnerability \u2014 continue to support the customer using available options without adding vulnerability details to the account.", "requires_customer_speech": false, "capture": [ { "field": "vulnerability_category", "type": "enum", "required": true, "prompt": "Which category applies?", "values": [ "REDUCED_INCOME", "LIFE_EVENT", "HEALTH", "CAPABILITY" ] } ] }, { "step_id": "V4", "stage": "VULNERABILITY", "action": "offer_support_options", "system": null, "instruction": "Consider and set out suitable support options before continuing: additional time to respond, an alternative communication method, payment support options, Direct Debit reinstatement where applicable, a clearer explanation of next steps, or escalation to a specialist team where required. Confirm the customer has understood them.", "requires_customer_speech": true, "capture": [] }, { "step_id": "V5", "stage": "VULNERABILITY", "action": "confirm_vulnerability", "system": null, "instruction": "Confirm on the record that the customer has stated a circumstance meeting the approved definition, then continue with the relevant account, billing, policy or complaint process. This confirmation is yours to make, not the system's.", "requires_customer_speech": false, "requires_explicit_confirmation": true, "confirms_fact": "vulnerability_confirmed", "capture": [] } ], "branches": [], "no_matching_branch": "ESCALATE_TL" } ], "corpus": [ { "pk": "CORPUS#VULNERABLE-CUSTOMER-PROCESS", "sk": "v1.0", "type": "PASSAGE", "article_id": "VULNERABLE-CUSTOMER-PROCESS", "article_version": "v1.0", "article_title": "Vulnerable Customer Process", "section_anchor": "#full-process", "_note": "Full text supplied by Cindy Jacobs (comment CJ4, 'esure input and output for integration demo.pdf') as the real source document to back the Vulnerable Customer Process citation. Document's own status line: 'Source document for demonstration, testing and training only. This process must be aligned to approved organisational policy, regulatory requirements and system permissions before operational use.'", "keywords": [ "vulnerable customer", "vulnerability", "financial resilience", "permission to record", "support need", "safeguarding", "adjustment" ], "passage": "1. Purpose\nThis process guides colleagues in identifying, recording and responding to customers whose personal circumstances may affect their ability to understand information, make decisions, communicate, manage payments or access a product or service. The aim is to provide fair, respectful and practical support without making assumptions or diagnosing the customer.\n\n2. Guiding Principles\n- Treat every customer with dignity, patience and respect.\n- Listen for indicators; do not label, diagnose or make assumptions.\n- Ask only what is necessary to understand the support need.\n- Explain why information is being requested and ask permission before recording vulnerability information.\n- Adapt the service to the customer's needs and confirm understanding.\n- Record facts, agreed support and review requirements using neutral language.\n- Escalate urgent safety, safeguarding or severe financial difficulty concerns through the approved route.\n\n3. When to Consider Vulnerability\nIndicators may be disclosed directly or noticed during the interaction. Examples include bereavement, reduced income, job loss, repeated missed payments, illness, disability-related support needs, caring responsibilities, domestic or financial abuse, low confidence with digital channels, difficulty understanding information, limited literacy or language needs, or a significant life event. An indicator is a prompt to explore support needs sensitively; it is not proof of vulnerability.\n\n4. Operational Process\n1. Recognise: Listen for a disclosure or signs that the customer may need additional support.\n2. Acknowledge: Thank the customer for sharing and respond without judgement.\n3. Explore: Ask how the circumstances affect the customer's ability to manage the current issue and what would help.\n4. Seek permission: Explain what information would be recorded, why it is useful and who may use it to provide support. Obtain clear permission before recording it, unless an approved exception applies.\n5. Record: Capture the customer's own words where practical, the functional impact, agreed adjustments, permission status and any review date. Avoid unnecessary medical or personal detail.\n6. Adapt: Apply appropriate service adjustments and provide information in a manageable way.\n7. Resolve or escalate: Address the immediate issue within authority. Escalate where specialist support, safeguarding review or additional approval is required.\n8. Confirm: Summarise the agreement, check the customer's understanding and confirm the next action, owner and timing.\n9. Review and close: Complete accurate notes, set any follow-up and remove or update temporary adjustments when no longer required.\n\n5. Suggested Conversation Wording\n- Explore: \"Thank you for letting me know. How is this affecting your ability to manage the account or the issue today?\"\n- Permission: \"With your permission, I can record the support you need so you do not have to explain it again. Are you comfortable for me to do that?\"\n- Preference: \"What would make this easier for you today?\"\n- Understanding: \"I have explained a few options. Would it help if I summarised them one at a time?\"\n- Closure: \"To confirm, we have agreed the following actions. Is there anything you would like me to go over again?\"\n\n6. Permission and Recording\nIf permission is granted, record only information needed to provide support. Include the customer's disclosed circumstance, how it affects the interaction or account, agreed adjustments, permission status, date and any follow-up. If permission is declined, do not record the vulnerability detail; record only that support was discussed and provide any assistance that can be delivered without retaining sensitive information. Follow the approved exception route if there is an immediate safety or safeguarding concern.\n\n7. Possible Support Adjustments\n- Use plain language and provide one step at a time.\n- Allow extra time, pauses or a scheduled callback.\n- Offer an alternative communication channel or accessible format where available.\n- Repeat or summarise key information and ask the customer to confirm understanding.\n- Arrange contact through an authorised representative in line with verification requirements.\n- Review affordable or flexible payment options permitted by policy.\n- Pause avoidable collections or cancellation activity while an approved review is completed.\n- Refer to a specialist support, financial difficulty or safeguarding team where appropriate.\n\n8. Escalation and Safeguarding\nEscalate promptly when the customer indicates immediate danger, abuse, coercion, inability to meet essential living costs, severe distress, an inability to make or communicate an informed decision, or when the requested adjustment is outside the colleague's authority. Keep the customer informed, share information only through approved channels and record the reason for escalation factually.\n\nQuick Decision Guide\n- Possible indicator only -> Ask a sensitive, open question about support needs; do not assume vulnerability.\n- Customer discloses a support need -> Acknowledge, explore functional impact and agree an adjustment.\n- Permission to record is granted -> Record the minimum necessary information and agreed support accurately.\n- Permission to record is declined -> Do not retain vulnerability detail; provide available in-call support and explain any limitations.\n- Immediate safety or safeguarding concern -> Use the urgent escalation route and follow safeguarding instructions.\n- Support need affects payment or cancellation -> Review permitted payment, pause or reinstatement options and obtain approval where required.\n\n9. Quality Checks\n- Was the customer listened to and treated respectfully?\n- Was the functional impact explored without unnecessary probing?\n- Was clear permission obtained before recording vulnerability information?\n- Was only relevant information recorded in neutral language?\n- Were suitable adjustments offered and applied within authority?\n- Were understanding, ownership, next steps and timing confirmed?\n- Was any necessary escalation or follow-up completed?\n\n10. Example Record\nDisclosure: Customer advised that reduced working hours have caused an inconsistent monthly income and difficulty maintaining Direct Debit payments.\nFunctional impact: Customer cannot pay the full outstanding amount today and is concerned about cancellation.\nPermission: Customer gave verbal permission to record the support need.\nAdjustment agreed: Information explained one step at a time; permitted payment options reviewed; account action referred for approval.\nNext step: Specialist team to contact the customer by the agreed time and confirm the outcome.\nReview: Reassess the adjustment at the next substantive contact.\n\nVersion: v1.0", "storage": "esure Vulnerable Customer Process (source doc, demonstration/testing/training only)", "storage_version": "v1.0" } ] }