> ## Documentation Index > Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt > Use this file to discover all available pages before exploring further. # B27 Service requests and complaints > Let customers and staff resolve servicing problems with ownership and customer-visible outcomes. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility Servicing manages a customer’s request or complaint as owned work: intake, assignment, response and closure. A saved case is evidence that the issue was raised, not evidence that an account was changed or funds refunded. | Attribute | Module definition | | - | - | | Entry condition | A customer/officer raises a servicing request or complaint. | | Owned records | Case, assignment, correspondence, status and closure evidence. | | Functional output | A customer-visible response and traceable completion of the requested service or referral. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations service queues and Customer Web/mobile own-case intake/status. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B22 Disputes chargebacks and remediation](/banking/modules/b22) | B27 owns general customer communication/case tracking; B22 owns a transaction dispute and scheme process. | | [B28 Communications documents and consent](/banking/modules/b28) | B27 creates the response/closure facts; B28 delivers approved notices/documents and tracks delivery. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Customer; branch service officer; complaint officer; escalation owner. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority. ## Worked Indian example Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above. **Fictional requirements illustration, not seeded data or approved banking policy.** Reference: SR-001 / debit with no ATM cash. | Stage | Example | | - | - | | Starting situation | A customer reports an ATM debit without cash delivery. | | Operator/customer actions | Create a scoped service case, link original transaction/journal evidence, route investigation to ATM/dispute teams and track their authoritative financial result. | | Expected normal outcome | The customer receives an accurate response; only a confirmed adjustment changes their balance. | | Failure or alternate outcome | Closing the support case does not itself execute a refund or erase the unresolved ATM exception. | No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution. ## Module flow diagrams Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below. Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts. ### Flow 1: Submit request to retain history ```mermaid theme={null} flowchart TD START["B27-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Submit request"] N0 --> N1 N1["route to permitted team"] N1 --> N2 N2["acknowledge"] N2 --> CHECK{"Case scope and workflow permitted"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N3 N3["investigate"] N3 --> N4 N4["perform separately authorised servicing"] N4 --> N5 N5["respond"] N5 --> N6 N6["close"] N6 --> N7 N7["retain history"] N7 --> RESULT RESULT{"Completion evidence verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ### Flow 2: Customer disputes closure to final response/remediation evidence ```mermaid theme={null} flowchart TD START["B27-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Customer disputes closure"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["apply approved reopening/escalation rule"] N1 --> N2 N2["independent review"] N2 --> N3 N3["final response/remediation evidence"] N3 --> RESULT RESULT{"Outcome verification"} RESULT -->|Yes| DONE["Record outcome, audit and return"] RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"] HOLD --> REVIEW["Authorised resolution; no blind retry"] ``` ## Required features Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering. | Feature | What the user or service does | Completion evidence | | - | - | - | | B27-F1: Service catalogue and structured request forms | Expose the enabled service catalogue and collect the required structured inputs. | Intake gets a reference and an eligible destination, not a fabricated bank-operation success. | | B27-F2: Assigned work queues and permissioned private content | Assign work within current institution/branch scope and approved visibility rules. | Private content remains unavailable until its separate visibility policy is approved. | | B27-F3: Complaints, responses and escalation | Record complaint review, response and adopted escalation stages. | Existing complaints stay deferred until new-project workflow approval. | | B27-F4: Financial remediation referral with separate approval | Refer proposed financial remediation to the correct independently authorised module. | Case agents cannot bypass approval/posting controls to claim a refund. | | B27-F5: Customer status, evidence and closure quality | Present accurate customer status and close with response and completion evidence. | Customer-visible closure agrees with the linked servicing result. | ## Required configuration Request types; routing; ownership; complaint stages; deadlines; reopening; escalation; remediation authority. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority. ## End-to-end journey 1 Submit request → route to permitted team → acknowledge → investigate → perform separately authorised servicing → respond → close → retain history. The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state. ## End-to-end journey 2 Customer disputes closure → apply approved reopening/escalation rule → independent review → final response/remediation evidence. Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history. ## Interfaces and data dependencies Approved request/complaint state policy; case ownership; action outcomes; notice delivery. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal. All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary. ## Current implementation and reuse **New Banking project: proposed, not built.** General support is built within bounds; complaints, private notes and reassignment remain explicitly held in the old project. Reviewed legacy feature boundaries: `service-requests`, `service-request-routing`, `staff-support`. See the source inventory on the [gap page](/banking/current-system-gap). Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module. ## Acceptance criteria and exception scenarios Explicit cases: Inactive case owner; foreign branch; close without response; customer cannot see private note. * Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel. * Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage. * Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference. * Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace. Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document. ## Required implementation inputs **Status: Pending institution confirmation.** Commissioned servicing workflows, permitted states, content visibility and accountable owners. Legacy complaints/private-note holds remain recorded dependencies. Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions). [Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix) This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.