← Omegro Working Hub
Customer Success Story · Template & Example

Customer Success Story

TLM Nexus: the worked example, and the template behind it

One finished story, written so the structure can be copied for every other business unit. The story is in section 02. The template that produced it is in section 03. Everything else is what you need to publish it and repeat it.

Prepared byThe Unspoken Pitch
ForOmegro
SubjectTLM Nexus (Marine)
ScopeTemplate plus one example

What this document covers

  1. Read before publishing
  2. The worked example: TLM Nexus
  3. The template: nine moves
  4. FAQPage schema
  5. Story copy, ready to paste
  6. Canonical and duplicate content
  7. How to reuse this

Two items in section 01 need to be closed before this can publish. Code and copy blocks have a copy button.

01Read before publishing

Two of these need action from Omegro. The rest are context so nobody has to guess later.

1. No customer quote exists. The source material is the TLM Nexus team describing the relationship, not the customer. Nothing has been written on the customer's behalf. A real, signed-off quote is needed before this goes live. The quote block is left visible and empty in the story so it does not get forgotten.

2. Confirm the availability claim. The source says both that the system "has not been unavailable once" and that availability has been "virtually 100% apart from notified downtime". The story reconciles these as no unplanned outage, which is the likely correct reading, but it is the strongest line on the page, so TLM Nexus should confirm the exact wording.

The customer is not named. The renewal source is anonymised. Keep it that way unless TLM Nexus confirms in writing that the customer can be identified.

Resolve and Advanced Search are not in this story. They are separate TLM Nexus work, and the source does not establish that Resolve underpins this contract. Hold them as their own story rather than folding them in here.

Run the canonical check. Section 06 covers it in full. Settle it before this and any TLM Nexus version are both live.

The vertical is confirmed, but treat it as provisional. Tanya confirmed on 29 July that TLM Nexus sits under Marine, and that the defence content should be used as is. That is the green light this story was waiting on, so it is written as approved.

Lynne noted the same day that outliers like this will likely be pulled under a broader Asset Management vertical in time. So Marine is correct today and may not be in six months. That is fine, as long as the vertical never becomes part of the URL. Section 06 covers how to publish it so a reshuffle costs nothing.

02The worked example: TLM Nexus

This is the finished story, exactly as it would go live. Read it alongside section 03 to see each move of the template doing its job.

Marine · TLM Nexus

Two renewals, no failed KPI: how TLM Nexus held a UK defence contract through open competition

TLM Nexus has run a UK defence customer's aircraft information management system since 2020, replacing a mainframe setup that had reached the end of its life. The contract has been renewed twice, most recently through open competition where no other supplier matched the capability offered. The team has met every SLA and never failed a KPI.
At a glance
VerticalMarine
Business unitTLM Nexus
EngagementLong-term managed software and consultancy partnership
RelationshipActive since 2020, currently in a renewed multi-year term
Assets managedAircraft structural, systems and engine information for a UK defence customer

What does TLM Nexus do for this customer?

TLM Nexus built and maintains the information management system that tracks structural, systems and engine data across the customer's aircraft fleet.

The system replaced an older setup running on mainframe technology that had reached the end of its life and was not flexible enough for the customer's secure network. It covers fatigue management, airworthiness and safety in one place.

The original build delivered around two thirds of what the customer wanted, limited by what was affordable at the time. Once they saw what the tool could do, they expanded it. Engine data sat outside the system at launch and is now fully inside it.

Why did the customer renew instead of switching suppliers?

They wanted continuity and a supplier they trusted to deliver, and when the contract went to open competition no other bidder offered the same capability.

The existing agreement sat on GCloud 13 and came to an end. The customer chose not to single-source the replacement. They ran it competitively on the basis of what suppliers put forward on GCloud 14, and TLM Nexus won a three year term with a further one year option.

That took around nine months of discussions to land. It is also the part of this story that carries the most weight with a defence buyer, because a competitive procurement outcome is harder to argue with than a testimonial.

What results has the customer seen?

Uninterrupted availability, one place for all of the data instead of parallel spreadsheets, and reporting the customer can run themselves.

On availability, the system has not gone down outside notified downtime across the life of the contract, and the team has met every SLA and never failed a KPI. For a system carrying aircraft structural fatigue and airworthiness data, that record matters more than any feature.

On consolidation, all aircraft structural elements, systems and engines now sit in the one system. The spreadsheets that used to track engine data separately have been turned off.

On reporting, the reports have been honed to the point where the customer no longer raises a request to get what they need. They pull daily, weekly or monthly reporting themselves. The result is less maintenance on their side and fewer queries than the old system generated.

What makes TLM Nexus different from a large prime contractor?

Size and access. A specialist provider can be reactive and proactive at the same time, with a flexibility that a prime contractor's structure makes difficult.

The relationship runs across every level of the customer's organisation, from commercial contacts through to the end users on the squadron, rather than sitting at contractual arm's length with the engineering team only.

Consultancy and software development sit together, which means the operational problem gets understood before anyone writes code. Ex-forces people on the TLM Nexus team shorten that further. A traditional software company would spend considerably longer with analysts to reach the same understanding.

How does a long-term contract avoid standing still?

Regular customer reviews and a change management module built into the tool itself, so improvement requests come from the people using it.

Reviews run monthly and quarterly. End users are invited to speak about their own experience directly rather than everything passing through a management representative. Change requests are filtered before they reach development, so the genuinely useful ones get through and the rest do not consume the roadmap.

Both the platform and engine sides of the system have been through three rounds of change on that basis, and the reporting capability was rebuilt so the customer could self-serve. The next phase covers structural and systems enhancements the customer has already specified, plus safety factoring that applies an adjustment factor to unmetered sorties where a meter has failed, so fatigue life can be assessed retrospectively.

Customer quote: pending sign-off. No customer-attributed quote exists in the material on file. This block stays empty until TLM Nexus supplies one and the customer approves it. Do not substitute the TLM Nexus team's own reflections on the relationship and present them as the customer's words.

Related: [Marine vertical page]  ·  [TLM Nexus business unit page]  ·  Last updated: [publish date]

03The template: nine moves

Every story follows the same sequence. Only the facts change.

  1. Outcome-led titleState the result, not the company name and the words "case study".
  2. Summary block, 40 to 60 wordsSits above the first heading. This is the block AI answer engines lift, so it has to make sense with no surrounding context.
  3. At a glanceVertical, business unit, engagement type, relationship length, assets managed. Never revenue or deal value. Treat the vertical as a swappable label rather than a fixed fact, because it is the field most likely to change.
  4. Question headingsFour or five, phrased the way a buyer would actually search or ask. Not Challenge, Solution, Results.
  5. Answer first, then detailOne direct sentence that stands alone, then the supporting paragraphs. If the first sentence needs the second to make sense, rewrite it.
  6. Customer quote, only if signed offLeave the block visible and empty rather than filling it. An unapproved quote is a bigger problem than a missing one.
  7. Internal linksThrough to the vertical page and the business unit page. The vertical belongs in the breadcrumb, not the URL, so a reorganisation never costs you a redirect.
  8. Visible last-updated dateStory age does not affect whether the results land, but a dated page reads as maintained and an undated one reads as abandoned.
  9. FAQPage schemaGenerated word for word from the visible questions and answers, so the two can never drift apart.

04FAQPage schema

Drop this into the page head or a Webflow custom code embed. The wording matches the visible questions and the opening answer sentence exactly. If the copy on the page changes, change this too.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "name": "What does TLM Nexus do for this customer?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "TLM Nexus built and maintains the information management system that tracks structural, systems and engine data across the customer's aircraft fleet."
      }
    },
    {
      "@type": "Question",
      "name": "Why did the customer renew instead of switching suppliers?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "They wanted continuity and a supplier they trusted to deliver, and when the contract went to open competition no other bidder offered the same capability."
      }
    },
    {
      "@type": "Question",
      "name": "What results has the customer seen?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Uninterrupted availability, one place for all of the data instead of parallel spreadsheets, and reporting the customer can run themselves."
      }
    },
    {
      "@type": "Question",
      "name": "What makes TLM Nexus different from a large prime contractor?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Size and access. A specialist provider can be reactive and proactive at the same time, with a flexibility that a prime contractor's structure makes difficult."
      }
    },
    {
      "@type": "Question",
      "name": "How does a long-term contract avoid standing still?",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Regular customer reviews and a change management module built into the tool itself, so improvement requests come from the people using it."
      }
    }
  ]
}
</script>

Keep this even though Google removed the rich result. Google published the deprecation notice on 7 May 2026 and FAQ rich results no longer appear in Google Search, so this markup no longer earns a visual result there. It still earns its keep as a machine-readable comprehension signal for AI answer engines, which is the audience this whole exercise is aimed at. Different job than it used to do, still worth doing.

05Story copy, ready to paste

The same words as section 02, with the heading levels marked, so it goes into Webflow without anyone stripping tags by hand.

[EYEBROW] Marine · TLM Nexus

[H1] Two renewals, no failed KPI: how TLM Nexus held a UK defence contract through open competition

[SUMMARY BLOCK] TLM Nexus has run a UK defence customer's aircraft information management system since 2020, replacing a mainframe setup that had reached the end of its life. The contract has been renewed twice, most recently through open competition where no other supplier matched the capability offered. The team has met every SLA and never failed a KPI.

[AT A GLANCE]
Vertical: Marine
Business unit: TLM Nexus
Engagement: Long-term managed software and consultancy partnership
Relationship: Active since 2020, currently in a renewed multi-year term
Assets managed: Aircraft structural, systems and engine information for a UK defence customer

[H2] What does TLM Nexus do for this customer?

TLM Nexus built and maintains the information management system that tracks structural, systems and engine data across the customer's aircraft fleet.

The system replaced an older setup running on mainframe technology that had reached the end of its life and was not flexible enough for the customer's secure network. It covers fatigue management, airworthiness and safety in one place.

The original build delivered around two thirds of what the customer wanted, limited by what was affordable at the time. Once they saw what the tool could do, they expanded it. Engine data sat outside the system at launch and is now fully inside it.

[H2] Why did the customer renew instead of switching suppliers?

They wanted continuity and a supplier they trusted to deliver, and when the contract went to open competition no other bidder offered the same capability.

The existing agreement sat on GCloud 13 and came to an end. The customer chose not to single-source the replacement. They ran it competitively on the basis of what suppliers put forward on GCloud 14, and TLM Nexus won a three year term with a further one year option.

That took around nine months of discussions to land. It is also the part of this story that carries the most weight with a defence buyer, because a competitive procurement outcome is harder to argue with than a testimonial.

[H2] What results has the customer seen?

Uninterrupted availability, one place for all of the data instead of parallel spreadsheets, and reporting the customer can run themselves.

On availability, the system has not gone down outside notified downtime across the life of the contract, and the team has met every SLA and never failed a KPI. For a system carrying aircraft structural fatigue and airworthiness data, that record matters more than any feature.

On consolidation, all aircraft structural elements, systems and engines now sit in the one system. The spreadsheets that used to track engine data separately have been turned off.

On reporting, the reports have been honed to the point where the customer no longer raises a request to get what they need. They pull daily, weekly or monthly reporting themselves. The result is less maintenance on their side and fewer queries than the old system generated.

[H2] What makes TLM Nexus different from a large prime contractor?

Size and access. A specialist provider can be reactive and proactive at the same time, with a flexibility that a prime contractor's structure makes difficult.

The relationship runs across every level of the customer's organisation, from commercial contacts through to the end users on the squadron, rather than sitting at contractual arm's length with the engineering team only.

Consultancy and software development sit together, which means the operational problem gets understood before anyone writes code. Ex-forces people on the TLM Nexus team shorten that further. A traditional software company would spend considerably longer with analysts to reach the same understanding.

[H2] How does a long-term contract avoid standing still?

Regular customer reviews and a change management module built into the tool itself, so improvement requests come from the people using it.

Reviews run monthly and quarterly. End users are invited to speak about their own experience directly rather than everything passing through a management representative. Change requests are filtered before they reach development, so the genuinely useful ones get through and the rest do not consume the roadmap.

Both the platform and engine sides of the system have been through three rounds of change on that basis, and the reporting capability was rebuilt so the customer could self-serve. The next phase covers structural and systems enhancements the customer has already specified, plus safety factoring that applies an adjustment factor to unmetered sorties where a meter has failed, so fatigue life can be assessed retrospectively.

[QUOTE BLOCK] Pending sign-off. Do not publish without a real, approved customer quote.

[RELATED] Marine vertical page · TLM Nexus business unit page
[LAST UPDATED] Insert publish date
[URL] /resources/tlm-nexus-defence-renewal    (flat path, no vertical segment. See section 06)
[BREADCRUMB] Resources › Marine › TLM Nexus    (the vertical lives here, not in the URL)

06URL structure, canonical and duplicate content

Settle all three before an Omegro version and a business unit version are both live. It takes five minutes up front and is a nuisance to unpick later.

Keep the vertical out of the URL

Publish each story on a flat path under the existing resources structure, so /resources/tlm-nexus-defence-renewal rather than /marine/tlm-nexus or /resources/marine/tlm-nexus. This is not a new convention to adopt. It is what omegro.com already does: the acquisition and insight posts all sit directly under /resources/ with no vertical segment in the path.

The reason matters more than the rule. A vertical in the path turns every reorganisation into redirect work. Lynne has already flagged that outliers like TLM Nexus will likely move under a broader Asset Management vertical. If the vertical is in the URL, that move means a new URL, a redirect, a period of split signals while search engines and AI systems catch up, and every existing link pointing at the old address. If the vertical is not in the URL, the same move is a text edit on the page. The story keeps the authority it has built.

The vertical still needs to be visible, just not structural. It belongs in three places: the At a glance table, the breadcrumb above the title, and the internal link through to the vertical page. All three are content, so all three are cheap to change. The URL is the one thing that is expensive to change, which is exactly why the least stable fact on the page should stay out of it.

Worth knowing before anything publishes. omegro.com currently has no canonical tags on any page, and /en/ serves a duplicate of the homepage with nothing indicating which version is preferred. That is a separate issue to this story, but it means the canonical guidance below cannot simply be assumed to be handled by the template. Whoever publishes needs to add the tag deliberately.

If the story already exists on the business unit's own site

The business unit site stays canonical, because that is where the content originated and where the customer relationship sits. The Omegro page carries a canonical tag pointing back to the business unit URL. Omegro still gets the page, the internal linking and the vertical context. The business unit keeps the search authority it has already built.

If the business unit has no public version

The Omegro page is canonical outright. Nothing to resolve. If the business unit later wants its own version, they carry the canonical tag back to Omegro, not the other way around.

If the content is substantially rewritten rather than republished

Two genuinely different pages, written for different audiences, are not duplicate content and do not need a canonical tag. The test is whether a reader would recognise one as a copy of the other. Reordered paragraphs and a new headline do not pass that test.

What to check before publishing, every time

Search the business unit's site for the customer name and the product name. Search the customer's own newsroom. Some defence and marine customers publish supplier stories themselves, and that version will usually outrank both of yours. Worth knowing before rather than after.

07How to reuse this

The nine moves in section 03 are the format. This is what actually makes a story work once the format is in place.

The format is not where the value sits. Specific, checkable facts are. "Never failed a KPI." "The engine spreadsheets have been turned off." "Won a competitive rebid because nobody else offered the same." Those are the lines a buyer remembers and an AI answer engine can quote. A story built to this exact template with vague answers will perform badly no matter how clean the headings are. If an answer could be said about any supplier in the portfolio, it is not finished.

Write the summary block last

It is the hardest fifty words on the page and it gets much easier once the body exists. Draft the questions and answers first, then work out what the whole thing amounts to.

Change the questions for every story

Do not reuse "why did the customer renew" on a story that is not about a renewal. Ask what a buyer researching that specific business unit would type into Google or ask an AI assistant, and build the headings from that. If a heading is not something anyone would actually search, it is there for the customer's benefit rather than the buyer's. That is a legitimate reason to keep it, but know which one you are doing.

Lead every answer with the answer

One direct sentence that makes sense on its own, then the detail underneath. This is the single change that does most of the work for AI answer engines, because it gives them something clean to lift.

Write stories that survive a reshuffle

The portfolio is still being reorganised, so assume any story you publish will outlive the vertical it was filed under. That means two habits. Keep the vertical out of the URL, as set out in section 06. And write the story about the customer and the result, not about the vertical, so that the words on the page stay true when the label above them changes.

A story that opens by explaining where a business unit sits in the portfolio dates the moment the portfolio moves. A story that opens with what the customer got does not.

No revenue or deal figures, ever

Only CSI publishes numbers. Qualitative descriptors only. This applies to customer contract values as well as anything at portfolio level.

Never publish an unapproved quote

If a story has no signed-off quote yet, ship without it. A missing quote costs very little. An unapproved one attributed to a defence customer is a different category of problem.

Sense-check the source material

Interview notes are usually rough, and a strong claim can rest on a half-finished sentence. Where a line is doing real work on the page, get the business unit to confirm the exact wording before it publishes. Two statements in the same set of notes can pull against each other without anyone noticing.