De centro de custos a conversor de valor: a conversão do antivalor no suporte técnico

Texto completo

1 Introdução

Na maioria das organizações de produto, o suporte técnico é registrado como centro de custo. O seu orçamento é visível, o seu resultado é contado em tickets encerrados, e a pergunta habitual é como torná-lo mais barato. Este artigo defende que essa abordagem é incompleta, e que aquilo que ela deixa de fora é a parte do suporte que mais importa para o produto.

O argumento usa o vocabulário da Teoria da Gestão de Valor (VMT) e da metodologia Æilus. Valor, antivalor, fluxo de valor, sistema de valor, transformador de valor e valor planejado, realizado e retrospectivo são usados conforme definidos no primeiro artigo desta série. O tratamento formal de Æ, a moeda de valor, é apresentado em Bolshakov (2026) e não é repetido.

A fonte principal é o artigo do Æilus "Technical Support Service - Anti-Value Conversion" (Bolshakov, 2025). Ele descreve o suporte como uma cadeia de transformadores de valor que recebem antivalor do cliente e o convertem em valor, com coeficientes que crescem a cada linha, e propõe dois coeficientes a serem medidos em cada etapa. Este artigo reformula o modelo, torna os coeficientes operacionais, define de quem é o valor que eles medem e propõe um protocolo de medição. Não contém dados de campo; todos os números do exemplo prático são ilustrativos.

O artigo se apoia nos axiomas da VMT A1 (contextualidade), A2 (interpretações múltiplas), A4 (assimetria entre plano e fato), A5 (independência do antivalor), A6 (realização no consumo), A7 (transformação), A12 (não conservação do valor) e A13 (comensurabilidade parcial), e nos teoremas T2 (inversão de fluxo), T4 (acúmulo de resistência), T5 (otimização local), T9 (fluxos ocultos), T14 (o valor não interpretado se perde), T15 (dependência de fronteira) e T16 (escalonamento por interpretação sem realização).

2 Por que o suporte é tratado como centro de custo, e o que isso oculta

2.1 A visão de custo é uma escolha de fronteira

A visão de centro de custo resulta de traçar a fronteira do sistema de valor em torno dos fluxos financeiros da empresa. Dentro dessa fronteira, o suporte consome salários e ferramentas e não produz nenhuma linha de receita. Segundo A1, o valor existe apenas dentro de um sistema de valor, e segundo T15, mudar a fronteira muda a conclusão sem mudar a realidade. A visão de custo é uma leitura correta de um sistema de valor, não uma descrição do que o suporte faz.

T2 afirma que um mesmo fluxo pode carregar interpretações opostas em sistemas diferentes. Uma interação de suporte registrada como custo pela empresa é, para o cliente, a remoção de antivalor: uma falha que deixa de doer, uma dúvida que deixa de bloquear o trabalho. A fonte lista dez tipos de valor para o cliente que o suporte entrega, desde a redução do antivalor de incidentes e a economia de tempo até a redução de riscos e a confiança. Nenhum deles aparece em um relatório de custos.

2.2 O que a visão de custo oculta

• Valor do lado do cliente. O suporte restaura o fluxo de valor do cliente. Se deixa de fazê-lo, a condição de participação (A8) do cliente fica em risco, e T7 prevê que o cliente se retira ou muda a forma de participação.
• Valor interno. A fonte cita três fluxos internos: informações sobre incidentes, pedidos de funcionalidades que os concorrentes têm e sugestões originais dos clientes. Segundo T9, uma estrutura sustentada por fluxos que o modelo não mostra está mal modelada ou mal delimitada. Um modelo de custo do suporte é um modelo desse tipo.
• Conversão. A fonte afirma que o suporte converte antivalor em valor, e que o resultado pode superar o antivalor original em ordens de magnitude quando um problema alcança linhas mais profundas e o produto. A12 permite isso: uma única causa raiz corrigida remove o antivalor de todos os clientes, e não apenas do que reportou.

3 O suporte como ponto de entrada do fluxo de antivalor

Todo produto entrega tanto valor quanto antivalor. Segundo A5, o antivalor é uma categoria independente: um cliente pode receber valor real de um produto e, na mesma semana, antivalor real de uma interrupção. O suporte é onde a maior parte desse antivalor entra na empresa como um fluxo observável. Este artigo o agrupa em quatro tipos, coerentes com a descrição da fonte para o atendimento de primeira linha:

• Incidentes. Algo funcionava e deixou de funcionar.
• Defeitos. Algo nunca funcionou como pretendido; o antivalor se torna visível quando o cliente o encontra.
• Confusão. O produto funciona, mas o cliente não consegue obter valor dele.
• Expectativas frustradas. O valor planejado e o realizado diferem. A4 afirma que isso é normal; o suporte é onde a lacuna é reportada.

Uma quinta entrada é o valor potencial: pedidos e sugestões. A fonte o trata separadamente e descreve o seu volume como não limitado. Ele compartilha o canal, de modo que a medição deve mantê-lo separado do antivalor para evitar a mistura de dois denominadores.

O ponto de entrada importa por causa de T4: a resistência se acumula. O antivalor deixado em uma fila se agrava em perda de confiança e, por T6, em redução da capacidade de realizar valor futuro. A dinâmica de filas no desenvolvimento de produtos está bem descrita (Reinertsen, 2009); a leitura da VMT acrescenta que o que espera em uma fila de suporte é antivalor em acúmulo no sistema de valor do cliente.

4 A cadeia de conversão

Segundo A7, transformação significa que um ator realiza o valor recebido, ou aqui absorve o antivalor recebido, e produz novo valor planejado. A fonte trata cada linha de suporte como um desses transformadores, cada um com o seu próprio Proprietário do Transformador de Valor (VTO).

4.1 Primeira linha

A fonte atribui à primeira linha a entrada do fluxo de antivalor em tickets estruturados, o amortecimento rápido do antivalor no primeiro contato, a manutenção do fluxo contínuo de valor, o roteamento, a coleta de dados, o gerenciamento das expectativas do cliente e a avaliação da profundidade do antivalor. O seu papel é o de filtro, amortecedor e acelerador. Na maior parte, ela restaura o estado anterior do cliente, razão pela qual a fonte lhe atribui o menor coeficiente. O gerenciamento de expectativas merece destaque: as atualizações de status não corrigem nada, mas reduzem o antivalor da incerteza, um caso direto de A5.

4.2 Segunda linha

A segunda linha recebe antivalor complexo: bugs difíceis, integrações, desempenho. A mudança fundamental, segundo a fonte, é passar de suprimir um problema para remover a sua causa raiz, e de um cliente para todos os clientes, já que as correções e as instruções atualizadas se propagam por toda a base de clientes. A segunda linha também constrói a base de conhecimento que aumenta a capacidade da primeira linha, alimenta o backlog com incidentes recorrentes e reduz o antivalor oculto, como a dívida técnica.

4.3 Terceira linha

A fonte chama a terceira linha de transformador de nível estratégico, que trabalha com antivalor enraizado na arquitetura, no código, nos protocolos e na lógica central. Os seus resultados são mudanças na funcionalidade e na arquitetura, e novos transformadores: ferramentas, scripts, monitoramento e verificações automatizadas que continuam convertendo antivalor. Ela também define as regras para as linhas inferiores, incluindo como valor e antivalor são medidos em casos complexos. A fonte observa que o ganho é difícil de quantificar até que as mudanças cheguem ao cliente, o que é A6 em termos operacionais.

4.4 Product Owner

A fonte coloca a equipe do Product Owner como o transformador seguinte e um sintetizador de valor. Ela prioriza o fluxo de todas as linhas, o alinha com a estratégia, avalia onde o valor para o cliente é maior com o menor antivalor em custo, tempo e risco, e acrescenta valor potencial proveniente das necessidades do mercado. O resultado é um plano de entrega que escala o valor existente e cria novo valor. A fonte relaciona isso ao PDCA: Plan a partir dos dados do suporte, Do pelas equipes de entrega, Check nos incidentes e nas métricas de valor, Act na estratégia e no produto. O produto atualizado então entrega valor novamente, o suporte captura o fluxo seguinte e o ciclo se fecha.

5 Os coeficientes propostos na fonte

5.1 Coeficientes nominais por linha

O resumo da fonte sobre o ciclo fechado afirma que o antivalor capturado na primeira linha pode ser transformado em valor com um coeficiente de x1 a x1,5; na segunda linha, x10; na terceira linha, x100. As sugestões dos clientes passam para a segunda e a terceira linha com volume descrito como não limitado, e o valor que o Product Owner devolve ao cliente é descrito como potencialmente praticamente ilimitado. O padrão: quanto maior o problema, mais alta a linha que ele alcança, e quanto mais alta a linha, maior o coeficiente. A fonte os oferece como ordens de magnitude, não como medições. Este artigo os trata como hipóteses.

5.2 VAM e ACM

A fonte conclui que dois parâmetros devem ser medidos em cada etapa:

• Value Amplification Multiplier (VAM), o coeficiente de transferência de valor: "Quanto valor foi recebido e entregue ao Cliente".
• Anti-Value Conversion Multiplier (ACM), o coeficiente de conversão de antivalor em valor: quanto antivalor foi recebido e quanto dele foi transformado em valor para o Cliente.

A fonte enuncia isto em palavras e não apresenta fórmulas. A leitura mínima por razão proposta aqui, para uma etapa s (primeira linha, segunda linha, terceira linha, Product Owner) ao longo de um período de revisão, é:

VAM_s = V_delivered,s / V_received,s

ACM_s = V_converted,s / AV_received,s

V_received,s é o valor que entra na etapa (sugestões ou valor potencial parcialmente transformado); V_delivered,s é o valor realizado para o cliente atribuível ao resultado da etapa; AV_received,s é o antivalor que entra na etapa; V_converted,s é o valor realizado para o cliente produzido a partir dele. Todos os termos estão em Æ.

Duas leituras decorrem da formulação da fonte. Os numeradores são valor para o cliente, de modo que planos, tickets e itens de backlog só contam depois de realizados pelo cliente (A6). E os dois coeficientes têm denominadores diferentes: um acompanha a amplificação do valor, o outro a conversão do antivalor. Um coeficiente ao nível da cadeia é ACM_chain = sum of V_converted,s / AV_received,1, com o antivalor de entrada como denominador e cada unidade de valor realizado atribuída a apenas uma etapa.

6 De quem é o valor medido

Segundo A1 e A2, um coeficiente sem um sistema de valor nomeado não tem significado. A cadeia toca quatro sistemas de valor:

Este artigo fixa a medição da seguinte forma. Os numeradores de VAM e ACM são medidos no sistema de valor do cliente, porque o valor realizado é a interpretação do receptor. Os denominadores são medidos na fronteira entre cliente e suporte: o antivalor tal como o cliente o vivencia e relata, registrado pela primeira linha. Os sistemas de suporte e de produto usam os coeficientes; o sistema da empresa pondera-os em relação ao custo. O VSO detém a política de agregação para comparar essas leituras, que são apenas parcialmente comensuráveis (A13). Se o suporte se medisse a partir do seu próprio sistema de valor, reportaria esforço e valor planejado. As definições da fonte apontam para fora, e o protocolo mantém-nas assim.

7 Um protocolo de medição

O protocolo abaixo é uma proposta, não testada em campo, concebida para funcionar com as ferramentas existentes de ticketing e de backlog.

7.1 Dados a registrar

• Na entrada: o cliente e o uso do produto; o tipo de entrada (incidente, defeito, confusão, expectativa frustrada, sugestão); uma estimativa de antivalor em Æ numa escala partilhada, confirmada com o cliente sempre que possível; domínios afetados.
• Em cada transferência: a etapa receptora e o motivo; o tipo de resolução (estado restaurado, corrigido para este cliente, causa raiz removida, novo transformador criado, item de backlog levantado); ligações dos tickets a itens de backlog e a versões; o valor planejado das alterações propostas, mantido separado do valor realizado.
• Após a entrega: valor realizado em Æ confirmado pelo cliente ou por um proxy acordado; número de clientes alcançados; uma reavaliação retrospectiva posterior.

7.2 Quem valida o valor realizado

O transformador que reivindica o crédito não valida o seu próprio valor realizado. O cliente interpreta-o, por confirmação explícita ou por proxies acordados previamente (o incidente não se repete, a funcionalidade é usada). O VTO de cada linha propõe estimativas e é responsável pela qualidade do registro. O VTO do Produto confirma quais alterações entregues remontam a quais entradas de suporte. O VSO arbitra as disputas de atribuição. O valor planejado é registrado, mas nunca entra num numerador, de acordo com A4 e T16: escalar uma reivindicação de valor apenas pela interpretação é estruturalmente instável. O x100 da fonte para a terceira linha é uma reivindicação desse tipo até que a alteração chegue aos clientes.

7.3 Cadência de revisão

• Por ticket, no encerramento: estimativa de entrada, tipo de resolução, valor realizado da primeira linha.
• Por linha, num ciclo regular curto: ACM e VAM dos itens concluídos, idade do antivalor em aberto nas filas (T4), motivos de escalonamento.
• Por sistema, num ciclo mais longo: o VSO e o VTO do Produto revisam as alterações entregues, as reavaliações retrospectivas, o fluxo total de entrada de antivalor e se os coeficientes por linha seguem a ordem que a fonte prevê.

Como a realização tem atraso, os coeficientes devem ser reportados por coorte, isto é, pelo período em que o antivalor foi recebido.

7.4 Armadilhas

Goodhart (1975) observou que uma regularidade estatística tende a colapsar quando passa a ser usada para controle. Em termos de VMT, isto é T5: a otimização local não garante melhoria global.

• Manipulação da contagem de tickets. Dividir um problema em vários tickets infla a produtividade. VAM e ACM são razões em Æ, não contagens, mas a contagem de tickets não deve ser definida como meta ao lado deles.
• Deflação da entrada. Subestimar o antivalor eleva o ACM. As estimativas de entrada precisam de uma escala partilhada e de confirmação amostral pelo cliente.
• Escalonamento excessivo. Se as linhas superiores apresentam coeficientes mais altos, o escalonamento torna-se tentador. Deve ser avaliado em relação às regras de escalonamento definidas pela terceira linha.
• Contagem dupla. O mesmo valor realizado pode ser reivindicado por várias etapas. Cada unidade é atribuída uma só vez.
• Ocultação da entrada. O melhor resultado é que chegue menos antivalor ao suporte, algo que o ACM não consegue ver. O fluxo total de entrada deve ser reportado ao lado dos coeficientes, e uma queda deve ser lida como um resultado.
• Perda de sinais. Segundo T14, o valor sem interpretação perde-se. O registro deve mostrar quantas sugestões e padrões chegaram a uma decisão de produto.

8 Relação com os domínios de serviço

A metodologia Æilus define um domínio como um contexto de interpretação de valor que impõe requisitos às práticas e aos resultados admissíveis. Os domínios não criam valor; impedem o antivalor não admissível. O suporte toca vários domínios típicos:

• Disponibilidade e Continuidade. Um incidente é uma violação deste contexto para o cliente. O dever da primeira linha de manter um fluxo de valor contínuo é o seu lado operacional, e o encaminhamento deve seguir a política do domínio quanto à criticidade.
• Segurança. A metodologia observa que o valor pode ser rejeitado por violar o contexto necessário para uma participação segura. Uma solução alternativa que enfraquece a segurança é registrada como novo antivalor, não como conversão.
• Arquitetura. A fonte exige que as decisões da terceira linha sejam verificadas quanto à integridade arquitetural, escalabilidade, desempenho e segurança.
• Gestão do Conhecimento e Melhoria Contínua. A base de conhecimento da segunda linha e o ciclo PDCA são práticas nestes domínios.

Decorrem duas consequências. O valor realizado contado no ACM deve ser admissível em todos os domínios relevantes. E o ACM agrega valor entre domínios parcialmente comensuráveis (A13), pelo que precisa da política de agregação explícita que a metodologia atribui ao VSO, com as políticas de domínio a cargo dos Domain Owners. Sem ela, adverte a metodologia, a otimização degenera em preferência local ou em manipulação de métricas.

9 Exemplo ilustrativo desenvolvido

Este exemplo é hipotético. O produto, os clientes e os números são inventados e deliberadamente redondos. Não são resultados e não testam os coeficientes da fonte.

Um produto tem uma falha recorrente numa integração de importação de dados. Num período, dez clientes a reportam.

• Entrada. O antivalor de cada cliente é estimado em 10 Æ, portanto AV_received,1 = 100 Æ.
• Primeira linha. Uma solução alternativa conhecida e atualizações de status restabelecem o trabalho; os clientes confirmam 120 Æ de valor realizado. ACM_1 = 120 / 100 = 1.2, dentro do intervalo nominal da fonte.
• Segunda linha. Encontra-se uma causa raiz de configuração; um padrão corrigido e um artigo da base de conhecimento chegam aos clientes que reportaram e a outros. Valor realizado confirmado: 400 Æ. ACM_2 = 400 / 100 = 4, abaixo do x10 nominal. No protocolo, isto é um resultado a examinar, não um erro a corrigir.
• Terceira linha e produto. O protocolo de importação mostra-se frágil; um redesenho e uma verificação automatizada entram no roadmap com valor planejado de 5.000 Æ. Nada foi entregue, portanto ACM_3 = 0 para esta coorte. Os 5.000 Æ são registrados e excluídos.
• Sugestões. Dois clientes pedem importações agendadas. Isto é valor potencial na trilha VAM e não entra no ACM.

Nesta revisão, ACM_chain = (120 + 400 + 0) / 100 = 5.2. Se o redesenho vier a ser entregue e os clientes confirmarem valor, a coorte da terceira linha é atualizada retrospectivamente; se causar uma regressão, esse antivalor é registrado contra a terceira linha. O exemplo expõe o que um piloto deve observar: a lacuna entre plano e fato na etapa mais profunda (A4, A6), o atraso de realização e a possível divergência em relação aos coeficientes nominais.

10 Limitações

Não há dados de campo aqui nem na fonte. Os coeficientes x1 a x1,5, x10 e x100 são ordens de grandeza propostas, plausíveis segundo o mecanismo descrito (uma correção escalada para muitos clientes, novos transformadores criados), mas não medidas. As fórmulas são a leitura deste artigo de definições verbais; outras leituras são possíveis. As estimativas em Æ dependem da interpretação, que, sob A2, é uma propriedade do valor, mas a comparação entre equipes ainda exige uma escala comum calibrada que este artigo não fornece. A atribuição entre etapas é designada ao VSO sem uma regra.

Um piloto que pudesse sustentar ou enfraquecer o modelo precisaria demonstrar:

• que pessoas diferentes fazem estimativas consistentes em Æ para os mesmos tickets;
• que o ACM da coorte ao longo de vários ciclos de revisão segue a ordem prevista por linha, quaisquer que sejam os valores absolutos;
• que o valor realizado foi confirmado pelos clientes ou por proxies acordados, e não pelas próprias linhas que o reivindicam;
• que o uso dos coeficientes foi seguido por um menor influxo total de antivalor, sem a manipulação listada na seção 7.4;
• que os coeficientes acrescentam informação além das medidas convencionais, como o tempo de restabelecimento do serviço (Forsgren, Humble e Kim, 2018).

11 Conclusão

Tratar o suporte apenas como centro de custo é uma escolha de fronteira. No sistema financeiro da empresa, o suporte é custo; no sistema do cliente, é a remoção de antivalor; no sistema do produto, é a informação mais direta sobre onde o produto falha. O modelo da fonte descreve uma cadeia de transformadores cuja alavancagem cresce da primeira linha à terceira linha e à equipe do Product Owner, fechando um ciclo PDCA de volta ao cliente, e propõe o VAM e o ACM para medi-lo. Este artigo deu aos coeficientes fórmulas mínimas, fixou seus numeradores no sistema de valor do cliente, contou apenas o valor realizado e admissível no domínio, e propôs um protocolo de registro, validação, revisão e proteção contra manipulação. Se as ordens de grandeza da fonte se sustentam é uma questão que só um piloto pode responder.

Referências

• 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.