
The case for connecting AI to a WordPress site holds when one named workflow, costed from your own records, saves more than the integration costs to build, secure, and run. Here is the worksheet, with one hypothetical example worked through so the arithmetic is checkable.
In short
The proposal that reaches a finance lead usually carries someone else’s numbers: an adoption percentage from a vendor survey, a lead-capture lift from a case study nobody can source. Finance leads are right to discount all of it. The only version of this case I would sign is built from inquiry volume, response times, loaded labor cost, and conversion history the company already holds.
Two different events
One argument should be retired first: that a site without AI integration is invisible to assistants. Public pages are already read and summarized. Integration matters for a different event, an agent booking a consultation or filing a quote request through a defined, permission-checked action, and only that event needs integration work. WordPress supplies the building blocks: the Abilities API, in core since 6.9, with a permission callback and JSON Schema validation on every registered ability, and the official MCP Adapter, at version 0.7.0 as of October 2026 and still pre-1.0. Pre-1.0 belongs in the cost model as software that will change.
The worksheet
Every line below comes from your own records or from a pilot. Where the source reads “pilot”, any number chosen before the pilot is a guess with a formula attached.
| Line | Source | Role in the arithmetic |
|---|---|---|
| Routine hours per month | Staff log them by category for a representative period | Baseline |
| Loaded hourly cost | Finance | Converts hours to money |
| Hours saved per month | Pilot, measured against the baseline | Benefit |
| Additional qualified leads per month | Pilot: inquiries captured when nobody was available | Benefit |
| Conversion rate and customer value | Sales history | Converts leads to money |
| Build cost | Discovery, ability registration, business-system integration, security review | One-time cost |
| Operating cost per month | Monitoring, model and API usage, maintenance | Recurring cost |
Three lines of arithmetic turn the table into a decision. Monthly benefit is hours saved times loaded cost, plus additional leads times conversion rate times customer value. Net year-one return is twelve months of benefit, minus build cost, minus twelve months of operating cost. Payback in months is build cost divided by monthly benefit less monthly operating cost. Run it twice: once with the pilot’s measured figures and once with both benefit lines halved. The halved run is the one that decides.
Customer satisfaction and readiness for agent-mediated demand are real and stay out of the arithmetic. Neither is a line that justifies the project alone.
A hypothetical worked example
The figures below are invented to show the arithmetic. They are no client’s results and they are not Mercury’s pricing. Substitute your own.
A twelve-person consultancy logs 60 routine hours a month handling inquiries, at a loaded cost of $55 an hour. A three-month pilot of one intake ability measures 24 hours a month saved and 3 additional qualified leads a month captured outside staffed hours. Sales history shows a 25% conversion rate and a $4,000 average customer value. Build cost was $18,000; operating cost runs $600 a month.
The halved run keeps every cost and halves both benefit lines: 12 hours saved and 1.5 leads a month.
| Line | Base case | Halved run |
|---|---|---|
| Hours saved × loaded cost | 24 × $55 = $1,320 | 12 × $55 = $660 |
| Leads × conversion × value | 3 × 0.25 × $4,000 = $3,000 | 1.5 × 0.25 × $4,000 = $1,500 |
| Monthly benefit | $4,320 | $2,160 |
| Net year one | $51,840 − $18,000 − $7,200 = $26,640 | $25,920 − $18,000 − $7,200 = $720 |
| Payback | $18,000 ÷ $3,720 = 4.8 months | $18,000 ÷ $1,560 = 11.5 months |
The base case looks comfortable; the halved case barely clears zero in year one. That gap is the finding: the project is worth doing only if the pilot’s measurements hold, and the person approving it should know that before signing.
The halved run is the one that decides.
What decides
Gates that can stop the project
A gate is worth having only when failing it changes what happens next. Decide before the pilot who has the authority to halt the rollout and what result would make them use it.
-
Assess
Audit the site, write the baseline, name an owner, cost every line in the table. If no workflow clears it, stop; the assessment did its job.
-
Expose one workflow
The narrowest permissions that serve it, read-only abilities where they suffice. Gate: a passed security review and staging acceptance tests.
-
Pilot and measure
Production, with monitoring and a human handoff for anything outside scope. Gate: measured results over a representative period, compared with the halved run.
-
Expand or stop
The next workflow only after the first met its numbers.
Security review is the line most proposals underfund. Every exposed ability is a new surface, and the review establishes what it reads or changes, under whose credentials, and what an agent could do with it when handed hostile input.
Strong candidate, caution, or wait
01
02
03
Where Mercury fits
Mercury Digital’s AI WordPress Enablement audit produces the inputs for this worksheet for one WordPress property: the baseline from your logged hours, the candidate workflow with its owner, a build and operating estimate across every line in the table, and the scope of the security review. If the halved run does not clear, the audit says so, and that is the cheaper outcome.
The worked example is hypothetical. Every input is invented to make the arithmetic checkable; none is a measured client result, an industry benchmark, or Mercury’s pricing.




