Commercial execution as software problem

The misdiagnosis

Most organisations treat commercial failure as a people problem. The sales team is undisciplined. The account managers are not following up. The wrong person is running the relationship. Leadership is not holding the right things accountable.

There is a version of this diagnosis that is true. People do shape outcomes. But organisations that act only on the people hypothesis, hiring better, training harder, managing more tightly, tend to find that the failure pattern returns. Different cast, same breakdown. The deal stalls. The handoff loses its thread. The client experience in month three does not match what was promised in month one. The record of what was agreed lives in someone's inbox, or in their memory, or nowhere at all.

This is what a software problem looks like when it has been misclassified as a people problem for long enough. The actual constraint is not human quality. It is the absence of a layer that holds context across time, across people, and across the full arc of a commercial relationship.

What the arc actually contains

Commercial execution is not a single activity. It is a sequence of distinct activities that must stay coherent across weeks or months and across multiple people who each carry partial knowledge of what has happened.

A prospect is identified. There are conversations. Something is proposed. Terms are negotiated. Expectations are set, not just in a contract, but in the dozens of smaller commitments that get made in passing and then silently shape what the client believes they are owed. The work begins. Scope evolves. The person who sold the engagement may not be the person delivering it. The person who delivers it may not be the person managing the ongoing relationship.

Each of these transitions is a potential loss point. Not because the people involved are careless, but because the system they are working in does not naturally carry the thread between them. Context, the full, granular understanding of what this relationship has been, what has been said, what has changed, what has been promised, exists somewhere across email threads, call notes, a CRM that was updated sporadically, proposals saved in a shared drive that no longer has the right naming convention, and the memory of the person who was most involved at the time.

None of it assembles itself. None of it surfaces at the right moment. The incoming person has to reconstruct the picture manually, and they never quite get all of it. This is where commercial relationships quietly start to erode, not in dramatic failures, but in the accumulation of small gaps between what the client expected and what the team understood they expected.

The process response and its ceiling

When this pattern becomes visible, the natural response is process. Write the handoff protocol. Define what a qualified lead actually means. Build a playbook that prescribes what should happen at each stage. Enforce CRM discipline so that the record exists and is accurate.

These interventions are not wrong. The absence of process is genuinely a problem. But process documentation has a ceiling: it describes what people should do, not what the system will do for them. And in a commercial workflow that runs across months and involves multiple people with competing priorities, the gap between described process and actual behaviour tends to be large.

The more honest observation is that detailed process documentation frequently reveals the absence of appropriate software by making the workarounds explicit. The handoff protocol exists because the system does not carry context automatically. The CRM discipline campaign exists because the system does not make updating it feel like the natural path of least resistance. People follow the process when they remember to, when they have time to, when they have not already moved on to the next thing. When the process is the only thing holding the context together, the context is always fragile.

Software that genuinely holds commercial context changes this equation. Not because it eliminates human judgement, as that judgement remains the most valuable part of any commercial relationship, but because it removes the cognitive overhead of maintaining the thread manually. When the system carries the context, people can direct their attention to the things that actually require human skill: the difficult conversation, the creative problem, the judgement call about what a client actually needs versus what they have asked for.

Designing for the real shape of the workflow

There is a reason most commercial software does not solve this well. The design model for most CRMs is a ledger: contacts, companies, activities, stage progression. This model captures some of what matters. It does not capture the full operating surface of commercial execution.

A commercial relationship does not move in a straight line. It doubles back. A prospect goes quiet for three months and then re-engages under different conditions. A delivered engagement expands into new scope. A client who was satisfied becomes dissatisfied because a specific commitment made early in the relationship was not tracked anywhere visible and was eventually missed. The relationship has a texture, a sequence of conversations, small agreements, tone shifts, moments where something important was said obliquely, that a linear pipeline view cannot hold.

Designing software that actually supports commercial execution requires accepting this non-linearity as the baseline condition. The system has to be built around how commercial relationships actually unfold, not around an idealised version of how they should unfold. That means persistent context that survives handoffs. It means surfacing the relevant history at the moment it matters without someone having to ask for it explicitly. It means connecting the front end of the commercial arc, qualification, proposal, negotiation, to the delivery and outcome at the other end, so that the promises made at the front are visible to the people who have to keep them at the back.

This is the design problem that Orbit is built to address. The framing is not a CRM replacement or a project management tool with a pipeline view attached. It is an operating surface for the full lead-to-launched-product arc, designed around the actual texture of commercial work rather than around the administrative ideal.

What services work teaches you

TUXX runs on the premise that the most honest product insight comes from doing real commercial work in real environments. Services work is not a route to product insight in theory; it is a route to product insight in practice, because the friction you encounter is actual friction, not a reasonable approximation of it.

What services work has made clear, repeatedly, is that the software layer is the structural missing piece. Teams with good people and thoughtful process still lose context. Still reconstruct pictures manually. Still have handoffs that lose thread because the system they hand off within does not carry the thread for them. The problem is not unique to any particular sector or client type. It is consistent enough to be structural.

The value of this pattern becoming visible in service work is that it gives product development a target that has been confirmed by direct experience rather than assumed from first principles. The service identifies where the friction is real. The product encodes an answer that can operate without constant human maintenance. TUXX and Orbit are not separate bets: they are different parts of the same research loop.

The AI dimension, stated carefully

In August 2022, the language model research landscape is moving quickly. It is worth being precise about what this means for commercial software, because the loose version of the argument is not the useful one.

Better language models can answer questions more fluently. That is genuinely useful in some contexts. But the commercial execution problem does not primarily need better answers. It needs persistent memory, reliable context assembly, and the ability to surface relevant history without someone constructing a query to retrieve it. These are distinct capabilities, and they are harder to produce than fluent question answering.

This distinction matters for how the research agenda is framed. The Orion work is oriented towards the specific capability set that a commercial operating surface actually requires, not general-purpose generation, but memory, retrieval, and contextual continuity across the full span of a commercial relationship. The underlying model capability is a component of that. The surrounding design is where the value materialises or does not.

The honest position in August 2022 is that the capability components are developing in the right direction but the product design work is where most of the leverage sits. That design work, making a commercial operating surface that is genuinely useful rather than impressive in a demo, is the thing that earns sustained attention right now.

The repeating signal

There is a useful heuristic for finding the right problems: look for where friction repeats in a way that cannot be attributed to individual error.

When multiple people, in multiple contexts, working with multiple clients, keep losing the same thread in the same way, that is not a people problem. That is a system problem. The friction is diagnostic. It marks where context is being rebuilt by hand instead of carried automatically. It marks where promises are living in someone's memory instead of in a shared surface that survives that person's attention moving on.

Commercial execution is dense with this kind of repeating friction. Not because the people doing it are careless, most are not, but because the software layer that should be carrying the thread has not been built with the right design intent. Building that layer, and building it around the real shape of commercial work rather than the administrative ideal, is the problem that earns sustained attention.

That is the orientation in August 2022. The work that follows from it is the work of building Orbit into something that holds.