Building a Digital Ecosystem for a Large Distributed Influencer Network

There were thousands of people influencing the business every day.

The strange part was that digitally, many of them almost did not exist.

Sales teams knew them. Dealers knew them. Local teams interacted with them. Schemes were run for them. Rewards were processed for them. Excel sheets, WhatsApp groups and internal systems contained fragments of information about them.

But there was no single relationship connecting all of these interactions.

A person could participate in one activity, receive a benefit through another process, speak to a field team through a third channel and appear in yet another database with slightly different information.

From the participant's perspective, the experience was equally fragmented.

There was no clear place to understand what was available, what they were eligible for, what they had earned, what they needed to do next, or whether the organisation even remembered their previous interactions.

That was the actual product problem.

It was tempting to describe the requirement as “build an app”. But an app was only one possible interface. The deeper problem was the absence of a digital identity, a continuous user journey and a reliable system of engagement.

What we needed was not another channel.

We needed an ecosystem.

The Happy State

Before discussing screens, features or technology, we tried to define what a good experience should feel like.

If everything worked properly, a participant should be able to enter the ecosystem once, establish their identity and then continue from there.

They should not have to repeatedly prove who they were.

They should know what opportunities were available to them.

If they participated in an activity, the system should recognise it.

If they became eligible for a benefit, they should be able to see it.

If money was due, they should know its status.

If they needed support, the system should already understand enough context to avoid making them start from zero.

The happy-state journey looked deceptively simple:

Discover → Join → Participate → Earn → Receive → Engage Again

That simplicity became an important product principle.

The complexity could remain inside the enterprise.

It should not be transferred to the user.

Designing the Solution

Once we mapped the complete journey, it became obvious that we were not dealing with a single product.

We were dealing with a connected set of product problems.

The first was identity.

Who was this participant? Could we reliably recognise the same person across activities, territories, devices and transactions? How much information did we really need at onboarding? Which details were essential immediately, and which could be progressively captured later?

The second was participation.

The system had to give users a reason to return. A digital platform with no recurring utility becomes an icon people forget to open.

That meant thinking beyond onboarding and creating repeatable reasons for interaction: schemes, transactions, content, support, earnings, tools, notifications and contextually useful information.

The third was trust.

In enterprise programs, users often tolerate a slow process once. They do not tolerate uncertainty repeatedly.

If someone completed an action, the system had to make the next step visible.

If a benefit was being evaluated, the status had to be understandable.

If there was a rejection, it had to be explainable.

If a payment was successful, the user should not need to call someone to confirm it.

The fourth was enterprise connectivity.

The participant-facing product could not become an isolated island. It needed to work with internal systems, eligibility rules, sales structures, financial processes and operational workflows.

This was where a large part of the real product work happened.

The screens were visible.

The integrations were not.

But the quality of the experience depended heavily on what happened behind the screens.

Product Architecture

We eventually thought about the ecosystem in layers rather than features.

Identity layer. A common participant identity became the foundation. The objective was to create a persistent digital relationship rather than a series of disconnected campaign records.

The principle was to avoid turning onboarding into a form-filling exercise. Every additional field had to justify its existence.

Engagement layer. The next layer answered a simple question: Why should the user come back?

The answer could not be “because we built an app”.

Some features drove frequent usage. Others were valuable only at specific moments. Both were important.

Transaction layer. Where possible, activities had to generate a reliable digital trail. This helped move the system away from manual verification and created the basis for faster eligibility, better visibility and improved control.

Benefit and incentive layer. Participants needed a transparent way to understand eligibility, earnings and settlement status.

This layer became particularly important because monetary benefits are not merely another feature.

They directly affect trust.

Communication layer. Broadcasting the same message to everyone was easy. Delivering the right message based on role, activity, geography, eligibility or lifecycle stage required a more structured approach.

The goal was to move from mass communication towards contextual communication.

The technology was not the hardest part.

The harder part was that the ecosystem sat between multiple organisational realities.

Sales teams wanted adoption.

Operations wanted process control.

Finance wanted accuracy.

Technology teams wanted stable requirements.

Management wanted scale.

Users wanted simplicity.

All of these expectations were valid, but they did not always point in the same direction.

Another challenge was that real users behaved differently from workshop users.

A flow that looked obvious in a conference room could become confusing in the field.

Network conditions varied.

Digital comfort varied.

Device quality varied.

Language preferences varied.

And the amount of attention a participant was willing to give us was usually much lower than we imagined.

This forced us to simplify repeatedly.

Some of the most useful product decisions were not features we added.

They were steps we removed.

We also had to resist the temptation to solve every edge case before launch.

In a large enterprise environment, that instinct can delay a product indefinitely.

Instead, we identified which exceptions could be handled operationally at first, which ones required immediate product support and which ones could wait until actual usage justified development.

There was another important challenge: organisational adoption.

A product can technically work and still fail.

If the field team does not understand why it exists, if existing processes continue in parallel indefinitely, or if users receive conflicting instructions from different parts of the organisation, adoption becomes a behavioural problem rather than a software problem.

That meant implementation had to be treated as part of the product.

Implementation

We approached rollout in stages.

The first objective was not scale.

It was learning.

Usage data helped, but numbers alone were not enough.

We combined analytics with feedback from field teams, support conversations and direct observation.

A funnel might tell us that users were not completing a process.

It would not always tell us why.

Once the major friction points were understood, we simplified the experience and gradually expanded the rollout.

The implementation rhythm became:

Pilot → Observe → Fix → Expand → Measure → Repeat

Training and field enablement ran alongside product releases.

Over time, the ecosystem started behaving less like a project being launched and more like a product being operated.

That was an important transition.

The important change was structural.

Instead of repeatedly starting from zero with the same participant, the organisation could build on an existing digital relationship.

Identity, activity, eligibility, communication and benefits could begin to work as parts of the same journey.

I initially thought the biggest challenge would be adoption.

It was not.

The biggest challenge was designing continuity.

Enterprise systems are often organised around departments.

Users are not.

A participant does not care which department owns onboarding, which team owns incentives, which system stores transactions or which workflow approves a benefit.

They experience all of it as one relationship.

The moment we started viewing the ecosystem that way, many product decisions became clearer.

The best enterprise products do not merely digitise individual processes.

They connect moments that the organisation previously treated separately.

And sometimes the most important product decision is not deciding what the next feature should be.

It is deciding what the user should no longer have to understand.