I run Echelon Advising LLC. We build and run AI infrastructure inside established companies, and the first question on almost every call is the one in this title. Here is the whole answer. It has no dollar figure in it, and that is deliberate, because a figure written before anyone has looked at your company is the one thing in this business that is always wrong.

Why can nobody quote you before a map?

The cost of AI automation is not set by the software. Models are cheap and getting cheaper. The cost is set by how your work actually moves: how many paths it takes, how many tools it touches, and how many decisions sit above it that a person has to keep. None of that is visible from a website form. It is visible in about two weeks of sitting with the people who do the work and following leads, quotes, money, and messages through the tools that carry them today.

So the policy is this. We map first. Then you get one set price for the whole build, in writing, before anything is built. It changes only if the scope changes, and only in writing. If we mis-scope, we absorb it. Ongoing operation is a separate monthly line, disclosed next to the build price, so nothing appears later.

What are the five things that set the price?

Every set price we write is built from the same five drivers. All five are visible in the operating map, which is why the map comes first and the price comes second.

  1. 01ScopeHow much of the business the system covers. One department that answers and books every lead is a smaller build than four modules running on one layer.
  2. 02Number of workflowsHow many distinct paths the work takes. Each one has its own inputs, exceptions, and acceptance criteria, and each one is built and verified on its own.
  3. 03Systems and their directionHow many tools the system reads from and writes to, and whether each connection runs one way or both. A CRM we only read is a smaller job than one we write into with a readback.
  4. 04Approval complexityHow many approval gates the design needs, who sits at each one, and how exceptions escalate. More gates is not worse. It is more design, and it is where your control lives.
  5. 05Work after launchWhat the system needs each month to keep running well: monitoring, retuning as tools and models change, the weekly report, and the next system built on the same layer.

Read them against your own company and you will know roughly where you sit before you speak to anyone. A single process with two tools and one approval is the small end. Four departments on one layer, reading and writing across a dozen tools, with approvals on money and customer messages, is the large end. The sizing tool turns five questions into a tier and a timeline, never a price, and it does not ask for your email.

What is inside the set price?

  1. 01The operating mapEvery system, record type, payment path, and daily ritual the work touches, with a baseline of repeat work, delays, and exceptions.
  2. 02The designWhat the system reads, what it does alone, where it stops, and which approval sits above each action, written down before anything is built.
  3. 03The build and the connectionsBuilt into the tools you already run. Every connection verified before anything depends on it. Nothing ripped out, nothing migrated.
  4. 04Review mode and launchThe system handles real work with your team approving every result, then narrow authority for proven actions, then a measured launch.
  5. 05Documentation and a named ownerThe runbook, the standing permissions list, and one person on your side who owns the exceptions queue.

What is not inside it is also written down: anything outside the agreed system, and any migration. If an install would force you to move platforms, it stops being an install and the timeline stops being weeks, so we say that in the map instead of discovering it in week eight.

What does the monthly operation line cover?

  • Monitoring every connection, so nothing unverified is ever presented as live.
  • The weekly report: what ran, what it handled alone, what waits on a decision, and who owns it.
  • Retuning when a tool changes its API, a model changes its behaviour, or your process changes.
  • The exception queue, reviewed with your named owner.
  • The next system, built on the same layer, scoped and priced in writing like the first.

It is month to month with thirty days' notice and no minimum term. You own the outcomes, the data, and the documentation either way. Third-party usage, such as model calls, telephony minutes, and software seats, bills to your own accounts and is not marked up. The pricing page lays out the same policy in full, and this article explains why we do not bill hourly and do not run open retainers.

How do you get to a number in two weeks?

  1. The mapping call. Bring one process the company still runs by hand. We map it together on the call, and you leave knowing what we would build, roughly how long it takes, and roughly what it would cost.
  2. The operating map. Two weeks with the people who do the work. The five drivers come out of it, and so does the baseline you will measure the system against.
  3. The set price, in writing. One figure for the build, the boundaries, the acceptance criteria, and the monthly line beside it. It holds unless the scope changes.

Where we start instead

Sometimes the mapping call shows that a full build is not the first step. We do not turn that into a refusal. We turn it into the first step.

  • If your process still changes every week, we start by making it repeat.
  • If the bottleneck is getting customers, we start with the system that answers and follows up with every lead.
  • If nobody inside owns the work yet, we name the owner in the map.
  • If one small tool already solves it, we tell you, and build what sits between the tools.

What we cannot yet claim

Echelon Advising LLC was founded in February 2026. The number of installs priced this way under our own name is small, and I would rather say that than imply a decade of pricing data. Every production number on this site comes from a system this team shipped and runs, not from a projection.

What I can claim is the policy itself, because it is written into every agreement next to the guarantee: If at least one system we deploy does not measurably save time, reduce a cost, or support revenue, we keep working until it does. If you want to see it applied to your own process, bring that process to the mapping call. You leave with the design, the price, and the date it goes live.