From Cost Centre to Value Converter: Anti-Value Conversion in Technical Support

Full text

1 Introduction

In most product organisations technical support is booked as a cost centre. Its budget is visible, its output is counted in tickets closed, and the usual question is how to make it cheaper. This paper argues that this framing is incomplete, and that what it leaves out is the part of support that matters most for the product.

The argument uses the vocabulary of the Theory of Value Management (VMT) and the Æilus methodology. Value, anti-value, value flow, value system, value transformer and planned, realized and retrospective value are used as defined in the first paper of this series. The formal treatment of Æ, the value currency, is given in Bolshakov (2026) and is not repeated.

The main source is the Æilus article "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). It describes support as a chain of value transformers that receive anti-value from the client and convert it into value, with coefficients that grow at each line, and it proposes two coefficients to be measured at every stage. This paper restates the model, makes the coefficients operational, states whose value they measure, and proposes a measurement protocol. It contains no field data; all numbers in the worked example are illustrative.

The paper relies on VMT axioms A1 (contextuality), A2 (multiple interpretations), A4 (asymmetry of plan and fact), A5 (independence of anti-value), A6 (realization at consumption), A7 (transformation), A12 (no conservation of value) and A13 (partial commensurability), and on theorems T2 (flow inversion), T4 (accumulation of resistance), T5 (local optimization), T9 (hidden flows), T14 (uninterpreted value is lost), T15 (boundary dependence) and T16 (scaling by interpretation without realization).

2 Why support is treated as a cost centre, and what that hides

2.1 The cost view is a boundary choice

The cost-centre view results from drawing the value system boundary around the company's financial flows. Inside that boundary support consumes salaries and tools and produces no revenue line. Under A1 value exists only inside a value system, and under T15 changing the boundary changes the conclusion without changing reality. The cost view is a correct reading of one value system, not a description of what support does.

T2 states that one flow can carry opposite interpretations in different systems. A support interaction booked as cost by the company is, for the client, the removal of anti-value: a failure that stops hurting, a question that stops blocking work. The source lists ten kinds of client value support delivers, from reduction of incident anti-value and time savings to risk reduction and trust. None appears in a cost report.

2.2 What the cost view hides

• Client-side value. Support restores the client's value stream. If it stops doing so, the client's participation condition (A8) is at risk, and T7 predicts that the client leaves or changes the form of participation.
• Internal value. The source names three internal flows: incident information, requests for features competitors have, and original client suggestions. Under T9, a structure sustained by flows the model does not show is modelled wrongly or bounded badly. A cost model of support is such a model.
• Conversion. The source claims that support converts anti-value into value, and that the result can exceed the original anti-value by orders of magnitude when an issue reaches deeper lines and the product. A12 allows this: one fixed root cause removes anti-value for every client, not only the reporter.

3 Support as the entry point of the anti-value stream

Every product delivers both value and anti-value. Under A5 anti-value is an independent category: a client can receive real value from a product and, in the same week, real anti-value from an outage. Support is where most of that anti-value enters the company as an observable flow. This paper groups it into four kinds, consistent with the source's description of first-line intake:

• Incidents. Something worked and stopped working.
• Defects. Something never worked as intended; the anti-value becomes visible when a client meets it.
• Confusion. The product works, but the client cannot get value from it.
• Broken expectations. Planned and realized value differ. A4 states that this is normal; support is where the gap is reported.

A fifth input is potential value: requests and suggestions. The source treats it separately and describes its volume as not limited. It shares the channel, so measurement must keep it apart from anti-value to avoid mixing two denominators.

The entry point matters because of T4: resistance accumulates. Anti-value left in a queue compounds into loss of trust and, by T6, into reduced ability to realize future value. Queue dynamics in product development are well described (Reinertsen, 2009); the VMT reading adds that what waits in a support queue is accumulating anti-value in the client's value system.

4 The conversion chain

Under A7, transformation means that an actor realizes incoming value, or here absorbs incoming anti-value, and produces new planned value. The source treats each support line as such a transformer, each with its own Value Transformer Owner (VTO).

4.1 First line

The source assigns first line the intake of the anti-value stream into structured tickets, rapid damping of anti-value at first contact, maintaining the continuous value stream, routing, data collection, managing client expectations, and assessing the depth of anti-value. Its role is a filter, a shock absorber and an accelerator. Mostly it restores the client's prior state, which is why the source assigns it the lowest coefficient. Managing expectations deserves note: status updates fix nothing, yet they reduce the anti-value of uncertainty, a direct case of A5.

4.2 Second line

Second line takes complex anti-value: hard bugs, integrations, performance. The source's key shift is from suppressing a problem to removing its root cause, and from one client to all clients, since fixes and updated instructions propagate across the client base. Second line also builds the knowledge base that raises first-line capacity, feeds recurring incidents into the backlog, and reduces hidden anti-value such as technical debt.

4.3 Third line

The source calls third line a strategic-level transformer working on anti-value rooted in architecture, code, protocols and core logic. Its outputs are changes to functionality and architecture, and new transformers: tools, scripts, monitoring and automated checks that keep converting anti-value. It also sets the rules for lower lines, including how value and anti-value are measured in complex cases. The source notes that the uplift is hard to quantify until changes reach the client, which is A6 in operational terms.

4.4 Product Owner

The source places the Product Owner team as the next transformer and a value synthesizer. It prioritizes the stream from all lines, aligns it with strategy, evaluates where client value is highest at the lowest anti-value in cost, time and risk, and adds potential value from market needs. The output is a delivery plan that scales existing value and creates new value. The source links this to PDCA: Plan from support data, Do by delivery teams, Check on incidents and value metrics, Act on strategy and product. The updated product then delivers value again, support captures the next stream, and the loop closes.

5 The coefficients proposed in the source

5.1 Nominal coefficients per line

The source's summary of the closed loop states that anti-value captured at first line can be transformed into value with a coefficient of x1 to x1.5; at second line, x10; at third line, x100. Client suggestions pass to second and third line with volume described as not limited, and the value the Product Owner returns to the client is described as potentially virtually unlimited. The pattern: the larger the problem, the higher the line it reaches, and the higher the line, the higher the coefficient. The source offers these as orders of magnitude, not measurements. This paper treats them as hypotheses.

5.2 VAM and ACM

The source concludes that two parameters must be measured at each stage:

• Value Amplification Multiplier (VAM), the value transfer coefficient: "How much value has been received and delivered to the Client".
• Anti-Value Conversion Multiplier (ACM), the anti-value-to-value conversion coefficient: how much anti-value has been received and how much of it has been transformed into value for the Client.

The source states these in words and gives no formulas. The minimal ratio reading proposed here, for a stage s (first line, second line, third line, Product Owner) over a review period, is:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s is value entering the stage (suggestions or partly transformed potential value); V_delivered,s is realized client value attributable to the stage's output; AV_received,s is anti-value entering the stage; V_converted,s is realized client value produced from it. All terms are in Æ.

Two readings follow from the source's wording. The numerators are value for the client, so plans, tickets and backlog items count only once realized by the client (A6). And the two coefficients have different denominators: one tracks amplification of value, the other conversion of anti-value. A chain-level coefficient is ACM_chain = sum of V_converted,s / AV_received,1, with intake anti-value as denominator and each unit of realized value attributed to one stage only.

6 Whose value is measured

Under A1 and A2 a coefficient without a named value system is meaningless. The chain touches four value systems:

This paper fixes the measurement as follows. The numerators of VAM and ACM are measured in the client's value system, because realized value is the receiver's interpretation. The denominators are measured at the client-support boundary: anti-value as the client experiences and reports it, recorded by first line. The support and product systems use the coefficients; the company system weighs them against cost. The VSO owns the aggregation policy for comparing these readings, which are only partially commensurable (A13). If support measured itself from its own value system, it would report effort and planned value. The source's definitions point outward, and the protocol keeps them there.

7 A measurement protocol

The protocol below is a proposal, untested in the field, designed to work with existing ticketing and backlog tools.

7.1 Data to log

• At intake: the client and product use; input kind (incident, defect, confusion, broken expectation, suggestion); an anti-value estimate in Æ on a shared scale, confirmed with the client where possible; affected domains.
• At each handover: receiving stage and reason; resolution type (state restored, fixed for this client, root cause removed, new transformer created, backlog item raised); links from tickets to backlog items and releases; planned value of proposed changes, kept separate from realized value.
• After delivery: realized value in Æ confirmed by the client or an agreed proxy; number of clients reached; a later retrospective re-evaluation.

7.2 Who validates realized value

The transformer that claims credit does not validate its own realized value. The client interprets it, through explicit confirmation or proxies agreed in advance (the incident does not recur, the feature is used). Each line's VTO proposes estimates and owns log quality. The Product VTO confirms which delivered changes trace to which support inputs. The VSO adjudicates attribution disputes. Planned value is recorded but never enters a numerator, following A4 and T16: scaling a value claim by interpretation alone is structurally unstable. The source's x100 for third line is such a claim until the change reaches clients.

7.3 Review cadence

• Per ticket, at closure: intake estimate, resolution type, first-line realized value.
• Per line, on a short regular cycle: ACM and VAM for completed items, age of open anti-value in queues (T4), escalation reasons.
• Per system, on a longer cycle: the VSO and Product VTO review delivered changes, retrospective re-evaluations, total anti-value inflow, and whether per-line coefficients follow the order the source predicts.

Because realization lags, coefficients should be reported by cohort, the period in which anti-value was received.

7.4 Pitfalls

Goodhart (1975) observed that a statistical regularity tends to collapse once it is used for control. In VMT terms this is T5: local optimization does not guarantee global improvement.

• Gaming ticket counts. Splitting a problem into several tickets inflates throughput. VAM and ACM are Æ ratios, not counts, but ticket count should not be set as a target beside them.
• Deflating intake. Underestimating anti-value raises ACM. Intake estimates need a shared scale and sampled client confirmation.
• Over-escalation. If higher lines show higher coefficients, escalation is tempting. It should be judged against the escalation rules third line sets.
• Double counting. The same realized value can be claimed by several stages. Each unit is assigned once.
• Hiding inflow. The best outcome is less anti-value reaching support, which ACM cannot see. Total inflow must be reported beside the coefficients, and a fall read as a result.
• Dropping signals. Under T14, value without interpretation is lost. The log should show how many suggestions and patterns reached a product decision.

8 Relation to service domains

The Æilus methodology defines a domain as a value-interpretation context that imposes requirements on admissible practices and outcomes. Domains do not create value; they prevent non-admissible anti-value. Support touches several typical domains:

• Availability and Continuity. An incident is a breach of this context for the client. First line's duty to maintain a continuous value stream is its operational side, and routing should follow the domain policy for criticality.
• Security. The methodology notes that value can be rejected because it violates the context required for safe participation. A workaround that weakens security is logged as new anti-value, not conversion.
• Architecture. The source requires third-line decisions to be checked for architectural integrity, scalability, performance and security.
• Knowledge Management and Continuous Improvement. Second line's knowledge base and the PDCA loop are practices in these domains.

Two consequences follow. Realized value counted in ACM must be admissible in every relevant domain. And ACM aggregates value across partially commensurable domains (A13), so it needs the explicit aggregation policy the methodology assigns to the VSO, with domain policies held by Domain Owners. Without it, the methodology warns, optimization degenerates into local preference or metric gaming.

9 Illustrative worked example

This example is hypothetical. The product, clients and numbers are invented and deliberately round. They are not findings and do not test the source's coefficients.

A product has a recurring failure in a data import integration. In one period ten clients report it.

• Intake. Each client's anti-value is estimated at 10 Æ, so AV_received,1 = 100 Æ.
• First line. A known workaround and status updates restore work; clients confirm 120 Æ of realized value. ACM_1 = 120 / 100 = 1.2, inside the source's nominal range.
• Second line. A configuration root cause is found; a corrected default and a knowledge base article reach the reporting clients and others. Confirmed realized value: 400 Æ. ACM_2 = 400 / 100 = 4, below the nominal x10. In the protocol this is a result to examine, not an error to correct.
• Third line and product. The import protocol is found fragile; a redesign and an automated check go on the roadmap with planned value of 5,000 Æ. Nothing has shipped, so ACM_3 = 0 for this cohort. The 5,000 Æ is recorded and excluded.
• Suggestions. Two clients ask for scheduled imports. This is potential value on the VAM track and does not enter ACM.

At this review ACM_chain = (120 + 400 + 0) / 100 = 5.2. If the redesign later ships and clients confirm value, the third-line cohort is updated retrospectively; if it causes a regression, that anti-value is logged against third line. The example exposes what a pilot must observe: the plan-fact gap at the deepest stage (A4, A6), realization lag, and possible divergence from the nominal coefficients.

10 Limitations

There is no field data here or in the source. The coefficients x1 to x1.5, x10 and x100 are proposed orders of magnitude, plausible on the mechanism described (one fix scaled to many clients, new transformers created) but unmeasured. The formulas are this paper's reading of verbal definitions; other readings are possible. Æ estimates depend on interpretation, which under A2 is a property of value, but cross-team comparison still needs a calibrated shared scale that this paper does not provide. Attribution across stages is assigned to the VSO without a rule.

A pilot that could support or weaken the model would need to show:

• that different people make consistent Æ estimates for the same tickets;
• that cohort ACM over several review cycles follows the predicted order by line, whatever the absolute values;
• that realized value was confirmed by clients or agreed proxies, not by the claiming lines;
• that using the coefficients was followed by lower total anti-value inflow, without the gaming listed in section 7.4;
• that the coefficients add information beyond conventional measures such as time to restore service (Forsgren, Humble and Kim, 2018).

11 Conclusion

Treating support only as a cost centre is a choice of boundary. In the company's financial system support is cost; in the client's system it is the removal of anti-value; in the product's system it is the most direct information about where the product fails. The source model describes a chain of transformers whose leverage grows from first line to third line and into the Product Owner team, closing a PDCA loop back to the client, and proposes VAM and ACM to measure it. This paper has given the coefficients minimal formulas, fixed their numerators in the client's value system, counted only realized and domain-admissible value, and proposed a protocol for logging, validation, review and protection against gaming. Whether the source's orders of magnitude hold is a question only a pilot can answer.

References

• Bolshakov, V. Technical Support Service - Anti-Value Conversion. aeilus.tech, 2025.
• Bolshakov, V. Domains and Policies. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Roles. Æilus methodology, aeilus.tech, 2026.
• Bolshakov, V. Value Management Theory and Employee-Centric Competitive Advantage: A System-Level Perspective. ÆVRI, 2026.
• Bolshakov, V. Value, Anti-Value and Value Flows: A Working Vocabulary for Practitioners. ÆVRI, 2026.
• Forsgren, N., Humble, J. and Kim, G. Accelerate: The Science of Lean Software and DevOps. 2018.
• Goodhart, C. A. E. Problems of Monetary Management: The U.K. Experience. 1975.
• Reinertsen, D. G. The Principles of Product Development Flow. 2009.