From four teams and weeks to one seller and minutes

An AI-assisted pricing and SOW engine for a $200M managed-services business — designed, built, and piloted solo in the final year at Lumen.

Designed for a field organization of several hundred sellers and a daily deal flow. Piloted with ~20 solutions engineers as power users. Handed over to a formal development team with code, workflows, and design documents before I left; I do not know whether it reached full rollout.

The problem

Pricing a managed-services deal was a relay race with four teams and at least three round-trips to the customer.

flowchart TD
  A[Seller gathers<br/>customer intent] --> B[Sales engineering<br/>qualifies]
  B --> C[Scoping questions<br/>to customer]
  C --> D[Presales / solutions:<br/>static manual calculators]
  D --> E[First-round pricing]
  E --> F{Customer review:<br/>quantities, scope}
  F -->|revise| B
  F -->|ok| G[Solutions presentation]
  G --> H{Review + reprice}
  H -->|revise| D
  H -->|agree| I[Solutions engineering<br/>hand-builds SOW]
  I --> J[Legal review]
  J --> K[Customer redlines]
  K --> L{Negotiation}
  L -->|loop| J
  L --> M[Signature]
  style D fill:#fde8e8,stroke:#c0392b
  style I fill:#fde8e8,stroke:#c0392b
  style J fill:#fde8e8,stroke:#c0392b

The days went into queues: waiting for a solutions engineer to run the calculators, waiting for the next customer meeting to validate quantities. The weeks went into the SOW: 40-plus hours of hand assembly, then a legal queue, then redlines. The seller — the only person in the room with the customer — could not produce a number.

The services were broad: managed services over infrastructure, cloud, security, and LAN/WAN, including LAN/WAN as a service. Every one had its own calculator.

Why I built it myself

I took the problem to the internal IT and tools team first, and we spent a year on it without converging. The disagreement was architectural, and in hindsight it was a reasonable one to have: their proposal was built on the company's Microsoft-native stack with a conversational front end, which is the right default for most internal tooling. My requirement was the opposite shape. Pricing had to be deterministic and identical every time, the SOW language had to be immovable so legal could approve it once, and the seller needed a guided question tree rather than an open chat. Those three constraints pointed at a transactional system with a narrow AI surface, not a chatbot over a knowledge base.

We also looked at off-the-shelf configure-price-quote products. Integrating, maintaining and licensing one to approximate the requirement was slower than building exactly the requirement.

I had the domain knowledge, enough AI fluency to direct a build, and a reason to move quickly, so I built a working version myself to make the argument concrete rather than continue it in the abstract. That turned out to be the faster path to agreement: once legal and IT could use the thing and see that the model never touched a clause or a number, the objections resolved. The system took weeks to months of my own time, end to end, and was handed to a formal development team with code, workflows and design documents before I left.

What I built

flowchart TB
  subgraph Client["Seller's device — browser, desktop, or phone"]
    UI[Node.js app]
  end
  subgraph Core["Self-contained system on company data-center infrastructure"]
    DB[(SQL catalog:<br/>every SKU, bundle,<br/>rate, assumption)]
    PM[Pricing model<br/>Python — owns every number]
    SOW[SOW template engine<br/>pre-approved legal language,<br/>static clauses]
    APR[Approval workflow<br/>deal value + non-standard scope]
    RBAC[Role-based access:<br/>seller / SE / approver / admin]
  end
  subgraph AI["Next-best-question service"]
    LLM[OpenAI API]
  end
  UI --> RBAC --> PM
  PM <--> DB
  PM --> SOW
  PM --> APR
  UI -- "question-tree state only<br/>(no customer data)" --> LLM
  LLM -- "next clarifying question,<br/>assumptions to validate" --> UI
  SOW -. designed, not built .-> EXT[Salesforce /<br/>contract management]
  style LLM fill:#e8f0fe,stroke:#1a56db
  style PM fill:#e6f4ea,stroke:#137333

The catalog. A SQL database holding every service and SKU across the portfolio, with bundles, rates, and the underlying calculation assumptions. Admins manage it directly; nothing is hard-coded.

The pricing model. The static spreadsheet calculators, rebuilt as deterministic Python. It produces every number the seller or customer ever sees. The model is never asked to price anything.

The app. A Node.js wrapper so the same workflow runs in a browser, on a desktop, or on a phone — because the point was to price in the room, not back at the desk.

The AI. An OpenAI API call at the points in the workflow where a seller might not know what to ask next. If the customer says they run 68 Linux servers, the seller may not know to ask which distribution and what support model. If the customer mentions operations in the US and Europe, the seller may not think to ask about GDPR. The model's job is to return the next clarifying question and the assumptions that will need validating. It is never given a price to produce and never given a customer to remember.

Data minimization by design. No customer name, quantity, site, or other identifying information ever left the system. What went to the API was the state of the question tree — "the customer has Linux servers; what should we ask next?" — not the customer's answers. This was a design rule from day one, not a control added later.

The SOW engine. Pre-designed templates with legal language baked in and held static. Because the model cannot rewrite a clause, legal could approve the templates once. A standard deal's SOW is generated from exactly what the customer asked for, at the click of a button, with no legal pass required.

The approval workflow. Anything non-standard — a service not in the catalog, or a deal value above a scrutiny threshold — routes to a manager or approver inside the system. No external review process.

Four roles. Sellers price and generate. Sales engineers refine. Managers and approvers clear exceptions. Admins manage SKUs, bundles, and calculation assumptions.

Designed but not built. Integration with Salesforce and the contract-management system. The interfaces were designed; I left before they were wired.

The after-flow

flowchart TD
  A[Seller captures inputs<br/>in the app, in the meeting] --> B[AI flags gaps,<br/>proposes next questions]
  B --> A
  A --> C[Budgetary price +<br/>assumptions + points to validate]
  C --> D[Emailed to customer<br/>from the app, same meeting]
  D --> E{Customer agrees}
  E --> F[One-click SOW from<br/>pre-approved templates]
  F --> G{Standard?}
  G -->|yes| H[Signature]
  G -->|no| I[In-app approval:<br/>value or scope] --> H
  style C fill:#e6f4ea,stroke:#137333
  style F fill:#e6f4ea,stroke:#137333

Sellers left meetings with a budgetary quote — and, once scope was agreed, a proposal — already in the customer's inbox.

What stood in the way

IT wanted a chatbot. The internal team's instinct was a conversational front end on the company's standard tooling. A pricing engine is not a conversation; it is a deterministic model with a small amount of guided intelligence at the edges. Getting that distinction understood took longer than building the system.

Legal had to believe the templates were safe. The concern was reasonable: if AI is involved, won't it rewrite our clauses? The answer was architectural. The model never touches the template. The template is static; the pricing model fills the variables; the language legal approved is the language that ships. Once that was understood, pre-approval followed.

"AI plus code" was not yet an accepted model. In 2024–25 the organization's mental model was either "AI does it" or "code does it." The argument I had to win — repeatedly — was that the right design is code for everything that must be exact and AI for everything that requires judgment, with a hard boundary between them. This is the same doctrine I later wrote down for my own systems as code measures, AI judges.

I rebuilt it five times. I was learning to direct AI while building. The early versions were one-shot attempts that drifted, added features nobody asked for, and could not be validated in pieces. What survived was a method: documented requirements first; understand the domain and the data; turn requirements into an architecture and a functional spec; then build with prompt templates in layers, validating each layer before the next. That method is the origin of the spec-driven approach I have used on every system since, including ones handling real-time data orders of magnitude more complex than this one.

Rollout and results

The tool went live with a group of about 20 solutions engineers as power users and beta testers. The plan was a phased rollout to sales teams by need and capability, running in parallel with the existing process — never a big-bang cutover.

During the pilot, several hundred live opportunities went through the system. Separately, it was back-tested against more than 1,000 historical opportunities to confirm it priced the same deal the same way the manual process had — an apples-to-apples parity check before any seller relied on it.

The timing claims are measured, not projected: the system generates pricing in minutes on every use, against a manual baseline of days. SOW effort dropped from 40-plus hours of human work to a few. Cost per SOW fell roughly 13×; API spend per deal was a few dollars, a rounding error against the labor it replaced.

Deals closed on tool-generated SOWs. During the pilot every one still went through the additional approval for comfort — a deliberate safety net — and none required legal to rework any part of the contract.

What didn't happen

I left before the phased rollout to the full field organization. I handed over the code, workflows, and design documents to a formal, IT-led development team — a clean handover, because everything was in GitHub and everything was documented, code included. Whether they took it past the pilot, I do not know.

What it taught me

This was the simplest system I have built with AI, and it was the one that taught me how. Everything since — real-time decision-support systems, multi-agent research pipelines, an evaluation and governance layer that grades a production system nightly — used the method that came out of these five rebuilds: specify before you prompt, keep the model out of the numbers, keep the data out of the model, build in layers, validate each one.

It also taught me that the hardest part of an enterprise AI deployment is rarely the AI. It is getting a legal team, an IT team, and a sales organization to believe that a system can be exact where it must be and intelligent where it can be, at the same time.

What I'd do differently

Simplify the design, and draw the responsibility lines earlier and harder: a deterministic code spine for everything that must be exact and repeatable, a probabilistic component for the things that require judgment, a data layer with its own contract, and an explicit role for the human. Putting as much as possible into code is the cheapest way to control hallucination and get repeatable output; the model should own only what code cannot. I'd make the LLM component reusable across workflows rather than bound to this one, and I'd add a local open-weight model as the default for the next-best-question job — it's well within a small model's reach, and the usage cost of a frontier API adds up on a system designed for hundreds of sellers. That is the doctrine I later wrote down for my own systems; this is where I learned it.