Industry: Financial services My role: Functional lead Delivered: End-to-end pipeline prototype, qualitative testing, and code and product handover Release status: Paused before production
An incoming customer email contains several jobs before anyone can respond: identify the request, find the customer, check what information is missing and decide who should handle it.
We built an AI-assisted pipeline to carry out that preparation and hand structured information into a customer-service workflow. It processed emails, redacted sensitive information before language-model processing, classified requests, looked up customers and prepared a record for case creation.
I was the functional lead. My work covered the functional requirements and operational handoff, including a recommendation on the CRM workflow. I also verified the pipeline end to end with the engineer who built it.
The pipeline worked in test. The stream was paused before production while the destination workflow remained unresolved. Both parts matter to the account of what we delivered.
Define the work beyond classification
The existing inbox combined manual triage with a rules-based bot. Replacing a category label was only part of the opportunity. For the output to be useful, it needed to carry the context required for someone to act on the request.
The functional specification covered stage-by-stage acceptance criteria, the category structure, sensitive-information handling and identity-check requirements.
Engineering turned that design into the following pipeline:
| Stage | Implemented in the prototype |
|---|---|
| Ingest and prepare | Receive the email, remove signatures and quoted threads, handle attachments and retain a thread identifier |
| Protect information | Redact personal, sensitive and payment information before language-model processing |
| Understand the request | Summarise, classify and extract the intent and information needed for handling |
| Match the customer | Query customer records and distinguish a match, multiple matches and no match |
| Check identity requirements | Flag requests needing identity verification and trigger a verification request |
| Prepare the handoff | Produce a structured record and queue message for downstream case creation |
The architecture used an event-and-queue pattern to fit the client's environment constraints. The technical lead owned that architecture, and the pipeline engineer built the stages.
The test implementation also included a CRM handoff prepared for demonstration. Full testing of that integration did not complete before the stream was paused.
The destination was a workflow decision
The open question was where the prepared email should land: a full CRM case, a lighter activity record or another handling approach.
I reviewed the options and recommended case management because it supported a defined lifecycle, service-level tracking and queue routing. Those capabilities were relevant to who would own the request after triage and how progress would be managed.
This decision affected the operating model, approvals and change required from the service team. A technically valid handoff would not resolve those questions on its own.
The team also considered alternatives, including lighter write-back and keeping assistance within the existing inbox. These remained options; they were not additional production paths we built and released.
What we verified in test
I worked with the pipeline engineer to verify the flow end to end. Checks covered customer lookup using different identifiers, unknown customers and example classifications.
That established that the stages connected and could process the examples we examined. It did not establish a measured classification accuracy rate.
A labelled evaluation set had been requested, but the available records do not show it being received. The evaluation work was subsequently cancelled. We therefore had qualitative checks, not a benchmark against a representative sample of real requests.
The human review workflow for low-confidence items had also been deferred. It was not a completed feature of this first build. These were material limits on what the prototype demonstrated.
Pause and handover
The downstream workflow decision remained open, and the associated production approvals had not progressed. Environment delays and competing programme priorities also affected the available delivery window.
The stream was paused, with remaining effort redirected. The final deliverable was a code and product handover. The handover discussions covered the pipeline, its costs and what remained unresolved. I supported that documentation and transition.
The handover transferred the work completed on the test-stage pipeline; the stream did not reach production during the engagement.
What was delivered
The engagement produced a connected prototype spanning ingestion, redaction, classification, customer lookup and structured handoff. It also produced the functional design and acceptance criteria needed to describe how those stages should behave, plus a recommendation for the downstream case-management approach.
My contribution combined workflow definition, operational options analysis, end-to-end verification and handover support. Engineering delivered the implementation.
There are no measured handling-time savings or accuracy improvements to report. The work demonstrated the pipeline in test; the destination decision, evaluation and operational review workflow remained unfinished when the stream stopped.