Pricing & engagements
The old way is optional.Start with the problem. Price the work it takes to solve it. Keep running costs and ongoing support visible from the beginning.
Find the bad clauseMap one process, identify the friction, and decide whether an automation pilot makes sense.
A bounded first implementation, usually around one source, one destination, and a clear handover.
A defined plan for monitoring, fixes, agreed support, and the next useful improvement.
The pilot range is an estimate for planning, not a fixed offer. Your written quote defines scope, taxes, third-party usage, milestones, exclusions, and ongoing costs.
What changes the quote
The number and quality of integrations, available access, and how reliably systems exchange information.
How much interpretation is needed, what rules can handle, and which actions require review.
The cost of a mistake, required monitoring, recovery process, and support responsibilities.
Example shapes
One lead source, field validation, CRM record, assignment, approved acknowledgement, and a visible failure alert.
Inbound messages, intent routing, approved responses, opt-out handling, human takeover, and conversation history.
Grounded retrieval, structured output, review controls, evaluation examples, usage monitoring, and a safe fallback.
The proposal identifies hosting, model, messaging, CRM, and other usage costs separately. We do not hide an unbounded usage bill inside a fixed implementation fee.
A narrower workflow may be a better fit. We explain the minimum useful scope instead of spreading the budget across several unfinished ideas.
The implementation needs an agreed operating owner. That can be a scoped support arrangement or a documented handover when your team can maintain it.
The initial 30-minute workflow audit is free. Detailed process redesign or a technical specification may be a separate paid scope.
Access, integration quality, exception handling, security, and the consequence of mistakes can change the real work significantly. The quote follows a bounded scope.
What changes an automation quote
Automation pricing depends on the number and quality of integrations, the condition of the data, the consequence of errors, the amount of judgment involved, and the controls required to operate the workflow safely.
Two projects that look identical in a flowchart can require very different engineering. A clean API and one approval step are not the same as browser automation, inconsistent spreadsheets, several account owners, and a regulated decision.
Official APIs, webhooks, test accounts, stable identifiers, and clear administrators reduce uncertainty. Missing APIs, restricted permissions, old systems, manual exports, and multiple account owners increase discovery, testing, and maintenance effort.
A predictable rule is easier to test than an open-ended judgment. AI steps require examples, prompt or retrieval design, evaluation criteria, review thresholds, and monitoring. A process with many legitimate exceptions needs more operating design.
A missed internal reminder and an incorrect customer commitment do not deserve the same controls. Retry behaviour, duplicate protection, logging, approvals, security review, response targets, and fallback requirements influence the scope.
The implementation fee is only one part of ownership. Model usage, messaging, hosting, platform subscriptions, monitoring, support time, and future changes should be visible so the business can compare cost with actual value.
Ask every provider to name the exact workflow, integrations, assumptions, exclusions, testing, ownership, documentation, support window, usage costs, and success measures. A lower price may simply move necessary work outside the quote.
Use one input source, one primary system, one clear outcome, a limited set of normal cases, and a manual route for the rest. A narrower pilot creates better evidence than a wide build that is difficult to diagnose.
Enough circling back.
One conversation. One workflow. A clearer way forward.
Let’s kill the busywork