Collabra: Building the Bymark Ecosystem's Knowledge Engine

Client: Bymark Holdings
Sector: Financial services technology and investment management
Services: Knowledge assistants, Team productivity, Custom application development

The brief

Bymark works with asset managers, fund service providers, and portfolio companies who share a familiar problem: strong teams, weak connections between them, and that gets harder still once those teams are distributed rather than sitting on the same floor.

The product teams know what's shipping. The sales teams know what clients are actually asking for. The marketing teams know what's landing and what's noise. Rarely does one team see what the others already know, and the gap costs more than time. It shows up as duplicated work, missed signals, and decisions made without context that already exists on another team, in another office, or with someone working remotely.

Bymark brought this problem to Zuko Group, and the two teams worked together on the specification: Bymark's read on how its own ecosystem of asset managers, fund service providers, and portfolio companies actually collaborate, paired with Zuko's technical delivery, design, and build. Neither half works without the other. That collaboration became Collabra.

Starting from the problem, not the feature list

Before any interface got built, Bymark and Zuko worked through the real question together: what specifically breaks when product teams, sales teams, and marketing teams don't share knowledge well, particularly when they're distributed across locations rather than down the corridor from each other.

Three things came up consistently: insight gets trapped with whoever generated it, contribution is a one-way street (information flows down from leadership, rarely up from the floor), and nobody managing the business has a live view of whether any of this is actually working.

A fourth problem sat underneath all three: whatever got built had to stay usable by Bymark's own team long after the build finished. Collabra was developed as four connected functions, each answering one of those problems directly.

Function one: a knowledge layer that survives beyond the person who created it

The starting point was capture. A conversation on a sales team reveals a product gap. A campaign run by a marketing team surfaces language that resonates. A client escalation exposes a process weakness. In most organisations, and especially in ones where teams work remotely or across multiple offices, that knowledge lives in someone's head or a chat thread on a channel other teams never see, and gets buried within a week. Collabra's knowledge layer gives it a structured home instead: contributions are tagged by team, topic, and relevance, so someone on a product team can find what a sales team already learned without having to ask, and a new joiner working from anywhere can search institutional context that would otherwise take months to absorb informally.

The decision that mattered most here, agreed early between the two teams, was making capture near-frictionless. Anything that adds steps to someone's existing workflow gets ignored within a fortnight, so automated processes in the workflow logic handle the categorising and connecting of each contribution, rather than asking users to file them correctly themselves.

Function two: turning employees into active contributors, not passive recipients

Most internal tools assume information flows one way, from management down. Collabra inverts that. The underlying principle Bymark wanted built in was that employees closest to clients and day-to-day product use hold insight that leadership doesn't have, and a system that only lets them consume misses most of the value.

So the contribution model was built as a first-class function, not an add-on: employees can surface ideas, flag friction, and respond to what colleagues have shared, with visibility that runs across teams rather than staying trapped in one department's own tools.

This is where the AI layer earns its keep, and its job here is content creation, not filing. It helps someone turn a half-formed note into a contribution that reads properly, so the barrier to sharing something isn't "do I have time to write this up."

Getting that contribution to the right team, without a permanent engineering team behind it, is handled by automated processes built into the workflow logic, categorising and routing rather than requiring custom rules for every new content type Bymark's teams introduced.

Function three: analytics that measure engagement, not just usage

A tool like this is only as good as an organisation's ability to tell whether it's working. The third function is a real-time analytics layer built specifically for management, separate from the day-to-day collaboration surface. It tracks participation and engagement patterns across teams and turns them into a live read on culture and productivity, the kind of signal normally gathered through a quarterly survey, if it's gathered at all.

Building this well meant resisting the temptation to just count logins and clicks. Usage metrics on their own tell a COO nothing about whether cross-team knowledge sharing is actually improving. The analytics layer instead surfaces contribution quality, cross-team reach, and response patterns, a measure that maps to the outcome Bymark's clients actually care about: whether collaboration is turning into performance.

Function four: a build Bymark's own team can run without us

The last problem to solve wasn't a feature at all, it was a dependency risk. A tool this central to how three teams work can't be one that only functions while an external developer is on retainer to change it.

Bymark was clear on this from the outset, and it shaped how Collabra was developed: Bymark's team can add a new content category, adjust how contributions are tagged, or reconfigure a dashboard view without raising a ticket with us first.

That doesn't mean what's underneath is simplistic. Model selection and prompt design still had to be right, content people are willing to publish under their own name, not a rough AI draft nobody trusts.

The automated categorisation in the workflow logic has its own bar to clear too: it only earns its place if it's consistently accurate, not just fast. The interface and workflow logic sitting on top of both were deliberately kept in Bymark's hands, in line with how we approach every build together: a client should own and control what gets delivered, not rent access to it.

Why the build order mattered

Sequencing the first three functions in this order (capture first, contribution second, analytics third) wasn't arbitrary. An analytics layer with nothing to measure is a dashboard of zeroes. A contribution model with no structured place for insight to land collapses back into scattered messages.

Getting the knowledge layer right first meant the other two functions had something real to work with from day one, rather than being retrofitted onto a system that wasn't built to hold the data they needed. Bymark's requirement that its own team be able to extend the tool ran underneath all three from the start, not bolted on at the end, which is the only way it holds up once that team starts extending it themselves.

The result

Collabra now sits inside the wider Bymark ecosystem as the tool connecting product teams, sales teams, and marketing teams, wherever they're based, for the asset managers, fund service providers, and portfolio companies Bymark works with, giving them a way to operate more intelligently without adding headcount or process overhead.

For Zuko Group, it's a clear example of the kind of partnership we're built for: a client who understands their own organisation's problem in detail, and a technical team that can translate that understanding into functions that solve it, then build those functions properly rather than shipping a demo.

Find out more about Collabra from Bymark.