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 rather than production, so it is potential shown, not a saving audited. We would rather publish a projection labelled as a projection 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, and the study says so plainly: it reached proof of concept, and nobody has run it at scale. What the work proved is 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 states it, 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 rather than arriving 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 rather than reviewing it afterwards. The detailed controls are HSBC's own, but the operating pattern transfers: in a regulated estate, adoption readiness is 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. It is also the pattern Tenhaw carries 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, the raw material exists; what the proof of concept established is that the analysis layer can be built and shipped rather than theorised.

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. The constant across both is the shape of the outcome: a working system you can judge with your own eyes rather than 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 rather than a feasibility paper, and because innovation, operations and risk had been coordinated throughout the build, 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, which is why Tenhaw's own AI Readiness Audit ends in working prototypes rather than slides.

For a single meeting, use it. The HSBC AI Voice Insights proof of concept sat a layer above that: natural language processing, sentiment analysis and entity recognition applied across an estate where millions of hours of calls and meetings were captured but never analysed, 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, which is the insight the study describes as 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, read by natural language processing, sentiment analysis and entity recognition rather than by more manual listening.

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, and that combination is what made emerging-theme detection and real-time dashboards possible rather than a searchable pile of words. The same extraction is what lets a write-up be generated instead of typed, which 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: the platform reached proof of concept rather than production. Themes and dashboards are worth more over a longer run, since they tell you what is rising across the estate rather than 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 rather than a quarterly slice. Scale sat in the brief for exactly 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 rather than in a hand-picked few. Sampling is still the sensible way to start, on your own recordings, while you are testing whether the analysis holds up before committing 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. The engagement was agile delivery, supplier negotiation and operational reporting, and the study labels it exactly that.

By changing working practices rather than 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 study shows its working rather than asking you to take the number on trust. 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 study also states the limit plainly: 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.

Because two habits from it transfer straight into agentic work. The first is baselining a process before claiming an improvement to it: the 60% on this page is quotable because there was a measured before. The second is counting the running cost of a change rather than only the cost of building it, which is what the supplier renegotiation exercised. The engagement itself was agile delivery, supplier negotiation and operational reporting, with no models and no agents, and the study says so. Those two habits are precisely 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, and from nothing technical. The relationships came out stronger rather than soured: 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 rather than a technical one: someone has to own the supplier lines, the way the Globelynx engagement did when £100k of savings came from renegotiation rather than from anything built.

Programme and Delivery Management, at £18k–£35k per month at published rates. The study names this itself, so a reader can price the equivalent engagement rather than guess. The Globelynx shape is exactly 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. The media work to date has been delivery and operational rather than agentic, and each study labels which it was.

Collate it continuously into trends, rather than assembling a report when someone asks. 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 precisely because there was a measured before: comparable delivery data existed 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 exactly 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 rather than slipping quietly. Globelynx ran 16 client deliveries and one major internal change project together, with iterative planning, stand-ups and retrospectives across all of it and timelines and dependencies coordinated across the whole set rather than team by team. 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 rather than behind it.

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 rather than from pressure on people. 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, when one engagement can carry both, because they are the same problem seen from two ends. 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, and 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 rather than down one project. At Globelynx timelines and dependencies were coordinated across 16 client deliveries and one internal change project together, which 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 rather than assembled into a report when someone asked, so a stretched team or a slipping supplier showed up as a trend rather than as an apology. Delivery lead times fell by 60% within six months once that coordination was in place.