Transgenia's Claude.ai Implementation Methodology

This is the operating manual Transgenia uses to implement Claude.ai inside a Mexican B2B distributor. It is not marketing, and it is not a promise of "digital transformation." It is the exact sequence of decisions we execute, over 5 phases and 30 days, so that by day 30 the client has enough evidence to scale, adjust, or discard the use case without guessing.

The manual is born from our own path as a registered Claude partner (Anthropic). Along that path our team completed the Delivery Methodology course of the Partner Badge · Claude Code, and with that training we generalized Anthropic's discipline (originally designed for software engineering pilots) to the real terrain of a distributor: international purchases, exchange rates, inventory, customs documents, and that margin that erodes before the sale even happens.

Two rules govern this manual and everything derived from it. First: no fabricated client numbers; when we illustrate with a figure, the public source is cited, or it is left as a diagnostic question for the client's real use case. Second: precise positioning. Transgenia is a registered Claude partner building toward full certification, with real deployment evidence. Not a certified partner (the final evaluation of the path is still pending). Not a candidate (that framing was left behind in August 2026). Both rules exist to protect the reader from the overselling that dominates the market.

Who this manual is for

This manual is written for three roles inside a B2B distributor:

• Operations Director or CEO: the person who approves the pilot and signs off on the success criteria.
• Owner of the candidate process (buyer, warehouse manager, cost analyst): the person who lives the process every day and will be the pilot cohort.
• IT or internal project sponsor: the person who coordinates access, baseline, and the link with Transgenia.

If your distributor is already evaluating "doing something with AI" but is still unclear on which process to measure first, with which baseline, and who owns adoption surviving week 3, this manual answers that.

1. Why a partner if Claude's AI already does everything?

It is the most honest question of any first meeting, and Anthropic does not dodge it: it appears explicitly in the introduction of the Partner Basecamp. They put it like this: "if models are commodities anyone can access, why bring in a partner when anyone can call the same APIs?" The answer also comes from the same material, and it is the one we apply here.

The bottleneck moved. When models were below the threshold, the hard question was "can the AI do this?" That question is already solved in most cases. Today's hard question is everything around the model: how you design the product on top of it, how you connect it to real data, how you measure quality, how you make people actually change the way they work. Anthropic says it without rhetoric: "the model is a commodity; the application layer is the product."

See Mermaid diagram

flowchart LR
    M["Model
~10 percent
Claude API commodity"]
    P["Prompts
~25 percent
instruction design"]
    C["Context
~30 percent
RAG, tools, memory"]
    E["Evaluation
~30 percent
quality, regressions, confidence"]
    G["Guardrails
~15 percent
safety, monitoring, escalation"]

    M --> P
    M --> C
    M --> E
    M --> G

    style M fill:#1e3a5f,color:#fff
    style P fill:#166534,color:#fff
    style C fill:#166534,color:#fff
    style E fill:#166534,color:#fff
    style G fill:#78350f,color:#fff

A partner who has already operated that 90 percent contributes four things the API by itself cannot: business context (knows which process qualifies for a pilot and which does not), application-layer design (prompts, RAG, evaluation and guardrails, not just the model call), honest measurement with a baseline (so that "after" is comparable to "before"), and change management (so that adoption survives week 3). Without those four, an AI pilot is an expensive toy. With those four, it is a decision with evidence on day 30.

This manual documents exactly those four layers.

2. Why most AI pilots don't reach day 30

The pattern repeats almost identically across sectors: a use case is chosen without qualifying it, launched without a documented baseline, no one is left internally accountable for the new process, and within weeks the pilot is silently abandoned. The failure is almost never the model. It is the absence of a methodology that pins down, before day 1, what will be measured, with which baseline, and who is accountable for adoption.

See Mermaid diagram

mindmap
  root((6 preventable
failures))
    No baseline
      prior number
      area Excel
      captured before day 1
    No champion
      peer referent
      not the most technical
      internal credibility
    Marginal case
      diffuse gain
      does not move director metric
      skipped Phase 0
    Supervised plateau
      team comfortable reviewing
      never moves to autonomy
      no peer demo
    Outdated documentation
      manual does not reflect process
      prompts not shared
      knowledge in one head
    Non-formalized handoff
      vendor left
      no one accountable
      no dated record

Each of the 6 failures has an antibody in the phases that follow. It is not philosophy, it is a checklist.

3. The 5 phases · overview

See Mermaid diagram

flowchart LR
    F0["Phase 0
Qualification
days 1-3"]
    F1["Phase 1
Pilot design
days 1-3"]
    F2["Phase 2
Measurement and ROI
days 4-30"]
    F3["Phase 3
Staged adoption
days 4-27"]
    F4["Phase 4
Closure and handoff
days 28-30"]

    F0 --> F1 --> F2 --> F3 --> F4

    style F0 fill:#166534,color:#fff
    style F1 fill:#166534,color:#fff
    style F2 fill:#1e3a5f,color:#fff
    style F3 fill:#1e3a5f,color:#fff
    style F4 fill:#78350f,color:#fff

Each phase has a verifiable exit condition. Without that condition, we do not advance. This gate discipline is what separates a pilot that produces a decision on day 30 from a demo that gets forgotten.

4. Phase 0 · Use case qualification

Not every process that "could use AI" deserves a pilot. The first decision is to distinguish between a marginal gain (saves time but does not change the business outcome) and a structural gain (moves a metric a director is already watching: margin per SKU, cash cycle, stockouts, dispatch time).

See Mermaid diagram

flowchart TD
    Start(["Candidate process"]) --> Q1{"Enough
volume?"}
    Q1 -- "no" --> Rej1["Discard
does not justify pilot"]
    Q1 -- "yes" --> Q2{"Clear
rules?"}
    Q2 -- "no" --> Risk["High risk
tidy process first"]
    Q2 -- "yes" --> Q3{"Baseline
exists?"}
    Q3 -- "no" --> Q3b{"Buildable
in 3 days?"}
    Q3b -- "no" --> Rej2["Discard
no before, no after"]
    Q3b -- "yes" --> Q4
    Q3 -- "yes" --> Q4{"Team
willing?"}
    Q4 -- "no" --> Rej3["Postpone
no cohort, no pilot"]
    Q4 -- "yes" --> OK(["Qualified pilot
proceed to Phase 1"])

    style OK fill:#166534,color:#fff
    style Rej1 fill:#7f1d1d,color:#fff
    style Rej2 fill:#7f1d1d,color:#fff
    style Rej3 fill:#7f1d1d,color:#fff
    style Risk fill:#78350f,color:#fff

The 4 filters, in order:

1. Volume. Does it happen often enough that automating it matters? A process that happens once a quarter does not justify a 30-day pilot.
2. Complexity. Does it have clear, repeatable rules, or does it depend on case-by-case undocumented judgment? High complexity without clear rules is a risk signal, not a pilot signal.
3. Measurement. Does a baseline exist today, even in Excel, or would we have to invent one? If you cannot measure the "before," you cannot prove the "after."
4. Team willingness. Is the person who lives the process willing to change their flow for 30 days? An enthusiastic volunteer outside the process validates that the tool is interesting, not that the real process improves.

Discard rule: high complexity plus non-existent measurement equals risk, not pilot. Postpone until the process is tidied up, or narrow the scope.

Use cases we have already qualified as structural in B2B distribution:

• Real landed-cost per SKU (freight, tariff, exchange rate, port handling, customs broker fees) instead of average costing that hides negative margins.
• International supplier follow-up agent and PO ETA, with reading of emails and attachments.
• Predictive inventory to reduce stockouts and free capital immobilized in slow-moving stock.
• Automatic reading and classification of customs documents (commercial invoices, pedimentos, packing lists, certificates of origin).

In each case, the metric that moves (margin per SKU, dispatch time, immobilized capital, capture errors) is a metric an operations director already watches. It is not a metric invented to justify the pilot.

5. Phase 1 · Pilot design

Once the use case is qualified, the pilot is designed with three non-negotiable decisions: the cohort, the operating scope, and the success criteria.

The cohort. It is whoever lives the process every day (the buyer, the warehouse manager, the cost analyst). Never an "enthusiastic volunteer" outside of it. An enthusiastic volunteer validates that the tool is interesting; we need to validate that the real process improves.

See Mermaid diagram

flowchart LR
    C1["Buyer
cohort"]
    C2["Warehouse manager
cohort"]
    C3["Cost analyst
cohort"]

    Champ["Internal champion
peer influence"]
    Lead["Area lead
unblocks resistance"]
    TGN["Transgenia facilitator
open hours"]

    C1 --> Champ
    C2 --> Champ
    C3 --> Champ
    Champ --> Lead
    Champ --> TGN

    style C1 fill:#1e3a5f,color:#fff
    style C2 fill:#1e3a5f,color:#fff
    style C3 fill:#1e3a5f,color:#fff
    style Champ fill:#166534,color:#fff
    style Lead fill:#1e3a5f,color:#fff
    style TGN fill:#78350f,color:#fff

The scope. It is defined in precise operating terms, not aspirational ones. Not "digitize purchasing", but "automatic follow-up of the document status of international purchase orders, from supplier confirmation to warehouse receipt". The rule is that an outside reader can say without ambiguity "this is in the pilot, this is not".

Standard duration is two full cycles of the task being tested. For a distributor this is usually 25 to 30 days, enough to capture real variation: a typical purchase order, a month-end close, a high-volume week.

Success criteria are set before day 1, never after, with four explicit components:

• Baseline: today's number, documented with source and date.
• Threshold: what change would count as success.
• Method: how it will be measured (which report, which field, who captures it).
• Date: when the result is evaluated.

Setting this after seeing the first results invalidates the entire measurement. It is the most uncomfortable rule in the manual, and the one that has saved the most pilots.

6. Phase 2 · Measurement and evidence (ROI)

The baseline is captured before kickoff. A "reconstructed" baseline after two weeks of piloting is already contaminated by the very change we are trying to measure.

We measure in four categories, adapted from software engineering in Anthropic's original course to real business operations:

See Mermaid diagram

pie showData
    title The 4 ROI metric categories of the pilot
    "Operational productivity" : 30
    "Quality and rework" : 25
    "Use and adoption" : 25
    "Team perception" : 20

• Operational productivity: person-hours per purchase order, per ETA reconciliation, per margin report.
• Quality and rework: capture errors, returns, cost discrepancies, orders that need to be reopened.
• Use and adoption: percentage of orders or documents that go through the AI flow versus the manual flow.
• Team perception: would the person who lives the process keep using it without being asked? This question is asked, verbatim, at the end.

The pilot result is reported as a number, with its translation into executive language, not as a list of technical observations. A sentence of the form "we went from X to Y person-hours per week in ETA reconciliation" is understood in the director's room. A sentence of the form "the agent correctly processes Z percent of supplier emails" is not, on its own. (X, Y, Z are format placeholders: each client closes their pilot with their own documented number.)

7. Phase 3 · Staged adoption

Real adoption follows a curve, not a switch. It goes from full review to autonomy across four stretches, and the dominant risk is not the initial drop: it is the plateau.

See Mermaid diagram

flowchart LR
    S1["Week 1
Supervised
autonomy ~20 percent
calibration"]
    S2["Weeks 2-3
Growing autonomy
~55 → ~80 percent
exception review"]
    S3["Week 4
Agent mode
~95 percent
process runs itself"]
    S4["Day 30+
Institutionalized
~100 percent
this is how we do it now"]

    S1 --> S2 --> S3 --> S4

    Plateau["Dominant risk:
supervised plateau"]
    Plateau -.-> S2

    style S1 fill:#7f1d1d,color:#fff
    style S2 fill:#78350f,color:#fff
    style S3 fill:#1e3a5f,color:#fff
    style S4 fill:#166534,color:#fff
    style Plateau fill:#101820,color:#FBA225,stroke:#FBA225

Week 1, supervised: the team reviews every agent output before using it. It is normal for velocity to drop this week. It is calibration, not failure.

Weeks 2-3, growing autonomy: the agent operates without review in already-validated cases; the team only reviews exceptions.

Weeks 3-4, agent mode: the process runs autonomously within the agreed scope, with exception reports.

Day 30 onward, institutionalized pattern: the AI-driven process is simply "how we do it now," documented and transferable to someone new in the role.

The most common risk is not the week-1 drop (expected). It is the plateau effect: the team settles into supervised mode and never advances. That effect is broken by a peer's demonstration who has already moved ahead, not by a vendor's motivational talk.

8. Phase 4 · Closure, champion and handoff

No pilot survives without an internal champion: the person who, inside the client team, becomes the reference for the new process. They are chosen by peer influence, not by being the most technical person on the team. The champion needs their peers to believe them, not to master the configuration.

A clean closure delivers, at minimum:

• Living process documentation (the client's internal CLAUDE.md): what the agent does, what it does not, whom to escalate to when something falls outside scope.
• Catalog of 3 to 5 reusable prompts or flows, already tested, that the team can run without depending on Transgenia for each variation.
• Checklist of the 6 preventable failures (Diagram 2), explicitly reviewed before declaring the pilot closed.
• Formal handoff record, with date, receiving owner, and the exact status of the process at the moment of handover.

Without a dated record and an accountable owner, the pilot is not closed. It is paused, waiting for someone to pick it up, which is exactly the "non-formalized handoff" pattern of Diagram 2.

9. 30-day operating rhythm

Five phases, each with a verifiable exit condition, and two scheduled touchpoints from day 1:

See Mermaid diagram

timeline
    title 30-day pilot operating rhythm
    Days 1-3 : Baseline and criteria signed
             : Cohort and champion identified
             : Operating scope locked
    Days 4-10 : First cycle with full human review
              : Prompt and flow calibration
              : Day-8 touchpoint with area lead
    Days 11-20 : Second cycle with exception review only
               : Growing autonomy
               : Day-15 touchpoint with area lead
    Days 21-27 : Agent mode in agreed scope
               : Weekly open-hours block
               : Living documentation in progress
    Days 28-30 : Documentation delivered
               : Champion formally designated
               : Showcase and handoff record

Touchpoints scheduled from day 1 (not reactive):

• Day 8 or 15, 30 minutes with the area lead, to unblock any resistance before it accumulates.
• Weekly open-hours block (60 min), which by the end of the pilot is facilitated by the internal champion, not Transgenia.

Day-30 showcase, in three 10-minute blocks: live demo of the process running, then before/after numbers, and finally an explicit conversation about continuity.

10. The day-30 decision

The manual is designed to produce a decision with evidence, not a report. At the closing showcase, the distributor walks out with one of three decisions:

See Mermaid diagram

flowchart TD
    Start(["Day 30
Showcase"]) --> Q1{"Did the
threshold metric
move?"}
    Q1 -- "no" --> Discard["DISCARD
use case
did not qualify"]
    Q1 -- "partial" --> Adjust["ADJUST
2 more weeks
with revised scope"]
    Q1 -- "yes" --> Q2{"Would the team
use it without
being asked?"}
    Q2 -- "no" --> Adjust
    Q2 -- "yes" --> Q3{"Champion
ready and
living documentation?"}
    Q3 -- "no" --> Adjust
    Q3 -- "yes" --> Scale["SCALE
next process
or widen scope"]

    style Scale fill:#166534,color:#fff
    style Adjust fill:#78350f,color:#fff
    style Discard fill:#7f1d1d,color:#fff

• Scale: the case moved the metric, the team adopted it, and the champion is ready. Next process or scope expansion.
• Adjust: there is movement but incomplete. Two more weeks with revised scope and recalibrated criteria.
• Discard: the case did not qualify. The learning is documented and the team is released. Discarding honestly on day 30 is a valid outcome, not a defeat.

11. Why this is also an asset for Transgenia

Every engagement executed with this methodology does not only deliver value to the client: it directly feeds Transgenia's status inside the Claude (Anthropic) Partner Program.

See Mermaid diagram

flowchart LR
    T1["Registered
minimum commitment:
10 certified
individuals"]
    T2["Select
10 active individuals
2 clients in production
1 public story"]
    T3["Elite
extended criteria
Anthropic-referred"]

    T1 --> T2 --> T3

    Today["Transgenia today:
Registered
building evidence"]
    Today -.-> T1

    style T1 fill:#166534,color:#fff
    style T2 fill:#1e3a5f,color:#fff
    style T3 fill:#78350f,color:#fff
    style Today fill:#101820,color:#FBA225,stroke:#FBA225

Anthropic's Partner Program Guide · Services Edition measures three dimensions without averaging (being strong in only one is not enough): certified individuals on the team, joint clients deployed in production, and publishable client stories. Every engagement executed with this manual is, at the same time, evidence toward those three dimensions.

The current and honest formulation, the same one we use with clients: Transgenia is a registered Claude partner building toward full certification, with real deployment evidence. Not a certified partner, not a candidate. The distinction matters because the market is full of providers hanging off the Anthropic logo without being able to show the path.

12. Next step

Before scheduling any call, ask yourself these four questions about the process you would like to automate: does it happen often enough to matter?, does it have clear rules or depend on undocumented judgment?, does a baseline number exist today, even in a spreadsheet?, is the person who lives the process willing to change their flow for 30 days? If your answer is "yes" to at least three of the four, you probably have a qualified use case for a 30-day pilot.

If your company operates with multiple brands, multiple suppliers or a high-SKU catalog, you have probably identified several of these friction points in our specific guide for B2B distributors, where we detail how this AI application layer looks on top of Odoo, multi-brand inventory and margin per project.

The first step is not to sign an AI project. It is a 15-minute diagnostic to qualify, with these same filters, whether your distributor already has a use case ready for a 30-day pilot.

This is an in-house operating manual by Centrum Transgenia S.A.S. de C.V., informed by the "Delivery Methodology" course and the "Partner Basecamp" of the Partner Badge · Claude Code certification path (Anthropic). Transgenia is a registered Claude partner (Anthropic); not a certified partner and not a candidate. No figure in this manual represents a specific client result.

Cited sources: Anthropic, "Introducing the Services Track and Partner Hub of the Claude Partner Network"; Anthropic, "Anthropic invests $100 million into the Claude Partner Network"; Credly, "Claude Partner Badge · Claude Code".