The data and AI engagements, answered in full.

Yes, the engineering transfers even though the product differs. The HSBC Voice Insights work applied natural language processing, sentiment analysis and entity recognition to enterprise voice data inside a regulated bank, with innovation, operations and risk in the room from the start. Those are disciplines agentic systems still stand on: extracting reliable structure from messy language, keeping privacy and accuracy intact at scale, and building alongside the people who own the controls. What does not transfer is production evidence. The platform reached proof of concept, so treat the study as engineering pedigree in a regulated environment, not as a claim that this system runs anywhere today.

It is a projection, and the study labels it as one. The proof of concept demonstrated that natural language processing, sentiment analysis and entity recognition could remove manual administration, note-taking and summarising across millions of hours of recorded calls and meetings, and 1.5M+ hours a year is what that removal was projected to be worth at HSBC's scale. Nobody has banked it. The platform reached proof of concept and stopped short of production, so it is potential shown, not a saving audited. A projection labelled as a projection is worth more to you than a banked-sounding number nobody can stand behind.

Working prototypes, not slideware. The build combined natural language processing, sentiment analysis and entity recognition over enterprise voice data, and shipped prototypes that auto-generated meeting summaries, detected emerging themes across conversations, and surfaced real-time dashboards. The point was to turn millions of hours of captured but unanalysed calls and meetings into usable intelligence, with privacy, accuracy and scale treated as requirements rather than afterthoughts. The study's own label for it is a proof of concept shipped, not theorised.

No. It reached proof of concept, and nobody has run it at scale. The work did prove that voice data could become a new source of business intelligence inside a regulated bank, which is why it still earned a place in HSBC's thinking on AI platforms. Tenhaw writes every case study this way. Where an engagement ended at a pilot or a proof of concept, the study says so, because a prototype described honestly tells you more about how a consultancy will report to you than a rollout implied and never delivered.

Privacy was in the task definition from the start, not retrofitted. The brief was to turn recorded calls and meetings into usable intelligence with privacy, accuracy and scale intact, so the constraint sat alongside the capability and never arrived as a late objection. In practice that meant coordinating innovation, operations and risk throughout the build, so the people who would have to approve adoption were shaping the work while it was being made. The detailed controls are HSBC's own. The operating pattern is the part that travels. In a regulated estate, adoption readiness gets built with the risk function, not presented to it.

Customer insight, operational inefficiency and risk signals, in HSBC's case buried across millions of hours of voice data that was captured but never analysed. Every call and meeting held information about what customers wanted, where processes were failing and where risk was emerging, and none of it was reachable because the only extraction method was a person taking notes. That is the shape of the problem in most large organisations: the data already exists and is already being recorded, so the cost is not collection but analysis. The HSBC proof of concept showed the analysis could be automated with natural language processing, sentiment analysis and entity recognition.

Because a prototype that risk sees for the first time when it is finished is a prototype that stalls. On the HSBC Voice Insights work, innovation, operations and risk were coordinated throughout the build, so the platform was moving towards adoption readiness while it was still being made rather than queuing for approval afterwards. In a regulated bank that is the difference between a demonstration and a candidate for deployment. Tenhaw carries the same pattern into agentic work now. The people who own the controls are in the room from the start, because retrofitting their requirements is slower than building to them.

Yes, and the HSBC proof of concept demonstrated it inside a major regulated bank. Applying natural language processing, sentiment analysis and entity recognition to enterprise voice data produced auto-generated meeting summaries, emerging-theme detection and real-time dashboards, turning a passive archive of recorded calls and meetings into intelligence the business could act on. At HSBC's scale the projection was 1.5M+ hours a year of manual administration removed. If your calls and meetings are already recorded then the raw material exists. The analysis layer that reads it can be built and shipped, and three months at HSBC produced one.

Three months, from James joining HSBC's Innovation Portfolio to a shipped proof of concept with working prototypes over enterprise voice data. For comparison, Tenhaw's current Agentic Proof of Concept is a fixed £20k–£55k and runs two to four weeks, a pace today's models and tooling make possible. What has not changed is the shape of the outcome. Both end in a working system you can judge with your own eyes, not a paper recommending one.

It did at HSBC. The Voice Insights proof of concept proved that voice data could become a new source of business intelligence, and that evidence shaped the bank's strategic direction on AI platforms. It carried that weight because it was shipped, not theorised. The case rested on working prototypes running over real enterprise voice data, and innovation, operations and risk had been coordinated throughout the build, so the result arrived with adoption readiness attached instead of a queue of unanswered objections. A working prototype changes a strategy conversation in a way no deck can. That is why Tenhaw's own AI Readiness Audit ends in working prototypes.

For a single meeting, use it. The HSBC AI Voice Insights proof of concept sat a layer above that, applying natural language processing, sentiment analysis and entity recognition across an estate where millions of hours of calls and meetings were captured but never analysed, and shipping prototypes that auto-generated summaries, detected emerging themes and surfaced real-time dashboards. A built-in summariser tells you what was said in the room you were already in. Reading the whole archive tells you what customers keep raising, where processes are failing and where risk is building. The study describes that as the insight buried in voice data. Both are uses of personal data, so the smaller tool does not remove the privacy work.

Because the conversation happens first, and almost none of it reaches you. At HSBC, millions of hours of calls and meetings were captured but never analysed, with insight about customers, inefficiency and risk sitting inside them, unreachable because the only extraction method was a person taking notes. A survey gives you the people who chose to answer, after the event, in your words. The recorded estate is everyone who called, in theirs. What the proof of concept established is that voice data could become a new source of business intelligence, with natural language processing, sentiment analysis and entity recognition doing the reading no team could do by hand.

It turns the specifics of a conversation into things you can count. Natural language processing gives you structure and sentiment analysis gives you tone, but entity recognition is what pulls out the names, products, amounts and references a call contains, so a stretch of speech becomes something you can group, filter and trend. At HSBC the three were used together over enterprise voice data. That combination is what made emerging-theme detection and real-time dashboards possible. Without it you have a searchable pile of words. The same extraction lets a write-up be generated instead of typed, and that is where the projected 1.5M+ hours a year of manual administration sat.

Summaries, usually, because that is where the removable administration sits and the people whose calls are analysed feel it immediately. The HSBC figure of 1.5M+ hours a year came from manual note-taking and summarising, and it remains a projection. That platform reached proof of concept and went no further. Themes and dashboards are worth more over a longer run, since they tell you what is rising across the whole estate and not just what happened in one conversation, but they only pay if someone in operations has already decided what they will do with the answer. At HSBC all three shipped inside a three-month proof of concept, so sequencing is rarely the real constraint.

A sample tells you what was happening. The whole estate tells you what is changing. Emerging-theme detection, one of the prototypes the HSBC proof of concept shipped, only means something if new themes can be spotted as they rise, and that needs continuous coverage. A quarterly slice will not do it. Scale sat in the brief for that reason, alongside privacy and accuracy, because the value was locked in millions of hours of calls and meetings that were captured but never analysed. Sampling is still the sensible way to start, on your own recordings, while you test whether the analysis holds up before you commit to the full pipeline.

Globelynx is a UK media and broadcast technology business, and the engagement ran nine months across 16 client deliveries and one internal change project. We introduced iterative planning, stand-ups and retrospectives, coordinated timelines and dependencies across the workstreams, renegotiated supplier engagements, and continuously collated operational data into trends leadership could act on. Within six months delivery lead times had fallen by 60% and client satisfaction had risen, and £100k of supplier savings were negotiated.

By changing working practices, not by buying anything. Iterative planning, stand-ups and retrospectives went in across 16 client deliveries and one internal change project. Timelines and dependencies were coordinated across the lot rather than per team, and supplier engagements were renegotiated to improve performance as well as cost. Those practices produced comparable delivery data, which gave the improvement a measured baseline, and the 60% reduction was measured against it with the client over six months. Teams that previously could not prioritise effectively got operational data to prioritise with, and decisions across Operations, Partnerships and Client Management, which had lacked actionable data, got sharper.

Yes, and the working behind the number is the part that matters. The reduction was measured with the client from their own delivery data over six months, against a baseline the agile practices themselves created. Iterative planning and retrospectives across 16 deliveries produced comparable data before any improvement was claimed. The limit is worth stating. This is our measurement of our own work, and it has not been independently audited. Most of the AI business cases we are shown fail earlier than that, on the missing before. A number with a measured baseline and a stated limit is a different class of claim from a number alone.

Two habits transfer straight into agentic work. The first is baselining a process before you claim an improvement to it, and the 60% on this page is quotable because there was a measured before. The second is counting the running cost of a change as well as the cost of building it, which is what the supplier renegotiation exercised. Nine months of agile delivery, supplier negotiation and operational reporting across 16 client deliveries and one internal change project is where both were learned. Those two habits are where the AI business cases we are shown most often fall over.

From renegotiating supplier engagements to cut cost and improve performance at the same time. Nothing technical about it. The outcome records supplier relationships strengthening alongside the price coming down. It sits in this study because an AI programme's cost line is never only the model, and a delivery partner who has had to defend a supplier line in a profit and loss account reads a vendor contract differently from one who has not. The commercial work is part of the delivery work, not an extra.

Usually because the case presented a build cost and omitted the running one. Inference has a monthly bill, the vendor contracts around it renew, the human reviewers the system now needs are salaried, and the tooling nobody cancelled keeps charging. None of that appears in a business case built around the cost of reaching a working demo, so year one looks like success and year two's profit and loss tells a different story. Catching it is a commercial habit more than a technical one. Someone has to own the supplier lines, the way the Globelynx engagement did when £100k of savings came from renegotiation.

Programme and Delivery Management, at £18k–£35k per month at published rates. That band means you can price the equivalent engagement rather than guess at it. The Globelynx shape is what that service covers: agile delivery and operational insight across many parallel workstreams, with operational data collated into trends leadership can act on. The price derives from a published rate card at twenty billable days a month, the same arithmetic behind every engagement price on the site.

Yes. Globelynx is a media and broadcast technology business in the UK, and the engagement there ran nine months: agile delivery across 16 client deliveries and one internal change, a 60% reduction in delivery lead times, and £100k of supplier savings negotiated. James also ran the visual rebrand team on the Discovery+ launch, which hit its CEO-set date, and Sky and F1 sit in his delivery and transformation background.

Collate it continuously into trends. Do not wait for someone to ask for a report. At Globelynx, decisions across Operations, Partnerships and Client Management lacked actionable data, so operational data was gathered continuously and turned into trends leadership could act on, and the outcome credits that insight with sharper strategic decisions. The mechanism matters. A one-off report describes the past, while a maintained trend line changes the next decision. It is also the discipline an automation programme needs later, because a business that has never measured a process cannot report a saving from changing it.

Yes, before anything else. The most common gap in the AI business cases we are shown is a firm proposing to automate a process it has never timed, then proposing to report the saving. The Globelynx 60% is quotable because there was a measured before, with comparable delivery data in place before any improvement was claimed. The cheapest week of an agentic programme is the one spent measuring the process you are about to change, and our four-week audit exists partly to close that gap before a build starts.

Put the internal work on the same plan and the same cadence as the client work, so it gets traded off in the open and does not slip quietly. Globelynx ran 16 client deliveries and one major internal change project together. Iterative planning, stand-ups and retrospectives covered all of it, and timelines and dependencies were coordinated across the whole set. Operational data was collated continuously into trends, so leadership could see what the internal project was costing and what it was worth, and choose deliberately. Within six months delivery lead times had fallen by 60% and client satisfaction had risen, with the internal change moving alongside the client work.

It went the other way at Globelynx. Delivery lead times fell by 60% within six months and client satisfaction rose over the same period. That is what happens when the speed comes from coordination. The changes were iterative planning, stand-ups and retrospectives across 16 client deliveries and one internal change project, timelines and dependencies coordinated across the whole set, and supplier engagements renegotiated to improve performance as well as cost. Clients experience that as dates that hold and fewer late surprises. Satisfaction suffers when speed comes from cutting the checks, not when it comes from removing the waiting between them.

Often yes, when the limit is coordination rather than hands. Globelynx had long delivery timelines, inconsistent coordination and little operational insight, and teams that could not prioritise effectively. What changed that was iterative planning, stand-ups and retrospectives across 16 client deliveries and one internal change project, coordinated timelines and dependencies, and operational data collated continuously into trends leadership could act on. Lead times fell by 60% within six months, which is capacity you are already paying for coming back into the business, and the study records the result as positioning Globelynx for scalable growth. If your delivery is already coordinated and instrumented, then the honest answer is headcount.

Yes. Delivery and supplier negotiation are the same problem seen from two ends, and one engagement can carry both. At Globelynx supplier renegotiation sat with the delivery work and produced £100k of savings alongside the 60% reduction in delivery lead times, and supplier relationships came out stronger rather than soured. Someone coordinating 16 client deliveries knows which supplier is actually holding up which date. That is leverage a price-only conversation never has. Those renegotiations cut cost and improved performance at the same time. It carries into AI work directly, because an AI cost line is never only the model, and someone has to own the contracts around it.

Look across the whole portfolio, not down one project. At Globelynx timelines and dependencies were coordinated across 16 client deliveries and one internal change project together, and that is where a clash actually becomes visible. Inside a single project the dependency looks like someone else's problem right up until the week it lands on yours. The other half is data. Operational information was collated continuously into trends, so a stretched team or a slipping supplier showed up as a trend before it showed up as an apology. Delivery lead times fell by 60% within six months once that coordination was in place.