Placeholder canvas
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages

Go Home

A Digital Twin Business Model in 40 Hours

Though long past the date when I should have ‘retired’, I just can’t resist interesting projects, like the one a new friend brought me a few weeks ago. It concerns a small but fast-growing B2B business, providing a management-system SAAS platform for a certain type of real estate company.

The business model is essentially simple. The company gets revenue from [a] implementation fees as clients come on board and [b] continuing SAAS fees from live clients already using the system. Operating costs are dominated by staff in the various teams – sales and marketing, platform development, client onboarding, and customer support. Then there are the costs of running the SAAS platform and the usual overheads of finance, HR, and premises.

The initial problem? … Clients have questions or problems with the platform, so raise support-request ‘tickets’. A support team works to resolve those tickets. Although they already struggle to cope with the rate these tickets arrive, the business expects to double in size this year, and keeps adding new features to the system! So, you may say – hire more staff! But it takes months to learn about the platform and how to resolve client issues, so new staff contribute little to solving tickets and need to be coached while they are learning by the very people who are already struggling to cope.

Meanwhile, new clients must be ‘on-boarded’ – getting them on the system and learning how to use it. But the onboarding team, too, can’t cope with the rate of new clients and the ever-growing feature-set, so those new clients ‘go live’ with too little understanding of the system, so they raise still more tickets. Even after onboarding, ‘novice’ clients continue to raise 3x the rate of tickets of more mature clients.

The wider system. The business has captured the most valuable potential clients over the last 4 years – those with the largest property portfolios, the greatest need for the platform, the highest revenue potential, but also the greatest demand for platform functionality. So the platform developers are under constant pressure to build and release new features. And that pressure means features are released with too many bugs, which leads to more support tickets.

Those tickets come in 3 types – easy “How do I do this?” questions; complaints about things that don’t work; and more complex implementation challenges. So the support team is split in 3 groups too. The overload for each team means that backlogs of unsolved tickets build up. When those backlogs get unacceptable, they have to run “ticket-bashing” sessions when anyone who can help gives up extra time to clear the backlogs. And those sessions are happening more and more often. This puts pressure on the staff, risking a rise in turnover and further loss of even the limited support capacity that exists.

The onboarding team already struggles with existing features, and all new features come with unknown bugs, in spite of developers’ efforts to find them. So clients get new features OK, but fall over more bugs as a result … so the support team gets more support tickets to handle … but they don’t understand the new features either.

And, because the best clients have already been won, the business has no choice but to go for the mid-and small-scale clients. But those clients are harder to win – they have to be made aware, have the platform’s functionality explained, and have to be helped over the challenges that they fear will arise if they adopt it. And then those smaller clients deliver less value when they are won! And they don’t have great staff resources themselves, so they generate proportionally more support requests. Except that they don’t need the fancy extra functionality demanded by the top-range clients.

What my friend needs. First, he needed to just get a handle on the growing imbalance between the flow of support tickets and the capacity of the service team to deal with those requests. So that’s what the initial model did. It showed just how badly the problem would escalate over coming weeks if nothing changed, and pointed to solutions.

But he wanted more than just a working model of the support team’s workload because he could see that was just a symptom of a more complex set of issues, encompassing the whole business, all the way from initial marketing right through to the product development and staffing that has to happen. And of course, he and his colleagues need to understand not only where business development and performance may be going, but the financial implications as well.

So he needs a complete “digital twin” business model, playing out how everything in the system changes over time – platform IT development; marketing and partner acquisition, promotion and sales to 3 client segments, client on-boarding and support; all that ticket-handling across 3 teams; the staff development for all these activities; and all the financial results. And because things change constantly, typical quarterly results and monthly management reports are no use – he needs a model showing how the business is working week by week.

To understand what is going on, we need history – and because the issues surfacing today were triggered by events way back in the past, we need a model that starts in 2021 and goes out to 2024 and beyond.

What we did. My friend is the perfect client – he really “gets” how a living business model works, how powerful it could be, and how to guide its development. And he is willing to put in the hard yards to chase down the data needed. (At least this business has the data, which is often not true. In those cases, we have to estimate and triangulate between known items to fill in the gaps).

So I actually had the lighter load in all this. I spent some 40 hours building the model with the client’s guidance. He put in twice that effort to get that data and figure out with colleagues what had really been happening.

BUT we did it! – a complete digital-twin model that they can now use to work out priorities and policies to fix the current challenges and get the business in a state where it can grow, sustainably, into the future. And do so without the pressures and crises that currently risk overwhelming it. And all by relentlessly following the 4 steps of the strategy dynamics method you can discover in our online course on how to build dynamic business models:

Dynamic Business Modeling

An online course that guides you in creating a quantified, simulated “digital twin” of your business, highlighting inter-dependencies and feedback points.

Society members get a 20% discount

Learn More

Recent Posts

Call for Presenters: Seminar Series

Call for Presenters: Seminar Series We at the System Dynamics Society are continually seeking vibrant and knowledgeable presenters for our ongoing Seminar Series. As we unfold the calendar, there’s always a place for more insights, experiences, and expertise to enrich...

From Bergen to Global: UiB’s System Dynamics Group

From Bergen to Global: UiB’s System Dynamics Group The System Dynamics Group, an autonomous research group at the University of Bergen (UiB) was established in 1971 by professor emeritus Svein Nordbotten. Inspired by the work of Jay W. Forrester, Nordbotten...

Upcoming Events

Recent Business cases

A Design Value Calculator: A System Dynamics Boardgame

A Design Value Calculator: A System Dynamics Boardgame EXECUTIVE Summary Product design is a specific form of complex innovation that touches all areas of an organization’s management. While entrepreneurs recognise the value of design, they often tend to focus...

Join us

One thought on “A Digital Twin Business Model in 40 Hours

  1. Hi Kim.

    My comment will be rather different than your solution, because I will not be paid by your friend, something that gives me more freedom about the solution proposed. I am too much more a client than a modeler.
    Before trying to use a more complex solution and simulation is always more or less complex, it seems to me that what drives the difficulties, is adding new features constantly. Stopping this would already reduce a lot of problems. Consultants would be more efficient in solving the tickets, they would not lose time learning new features, the method would be easier to teach to new employees and to the clients etc.
    Now about the pressure of the clients to have more features, it is partially due to the fact that they already do not master the current version because of too many features already that are constantly updated.
    One solution is to teach them how to cope with a solution that will never be perfectly adapted to all of their wishes. And this is true with all models. If the client is used, when facing a difficulty, to ask for a solution without effort, he will readily do it all the time without trying to solve the problem by himself.
    If one stops at least for a while (that can be quite long) adding new features and teaching the clients how to work by themselves special cases, I think that it will solve more than 50% of the difficulties and without the need of any modeling.
    And I think that the tendency to over complicate models and making the client believe that it will solve their problems and not teaching them to work by themselves with less complex models is one of the main reasons of the general lack of growth of SD.
    Best regards;
    JJ

Leave a Reply