m3ter, usage pricing, and Agentforce Revenue Management

A product manager hears that Salesforce bought a metering company and asks, in the same meeting, what to charge per API call. Someone writes a number on the whiteboard because the silence is uncomfortable. The number is not in the announcement. It is also not in your contracts. It is now in a photo of the whiteboard, which is how fictional prices become internal policy.

Wipe the number off. The acquisition tells you what kind of problem m3ter was built to work on. It does not tell you your price.

#What closed on 1 July 2026

The close notice says: "Salesforce completed its acquisition of m3ter on July 1, 2026." m3ter is metering and rating for usage-based pricing, aimed at Agentforce Revenue Management. Metering is how you count what a customer used. Rating is how a count becomes a charge under a rule you wrote. Usage-based pricing is the commercial shape those two activities serve. The aim is Agentforce Revenue Management, which is a direction for where the work is pointed, not a statement that every Revenue Cloud org gained a meter on 1 July 2026.

Check your edition and your order form before you brief finance that the feature is already theirs. A completion date is about the companies. Entitlement is about your contract. Keep those files apart.

You will hear the product discussed as if the price list arrived with the code. It did not. Rating without your rule is a calculator with no buttons labelled. The buttons are the work.

#Do not invent a price per call

The announcement does not contain a price per API call, per agent action, per thousand events, or per any other unit. Do not borrow one from a blog, a rival's public rate card, or a figure that made a workshop feel decisive. A price you invent will be copied into a quote template, and a customer will eventually see it. Then you will have to explain a number nobody agreed.

If you sell usage, the price is a commercial decision. Legal, finance, and the product owner make it. They make it per product, often per edition of that product, with a start date. This guide cannot make it for you, and a Salesforce partner should not make it in a sidebar of a technical proposal. When a proposal includes a sample rate "for illustration", treat the sample as a risk. Illustrations escape.

What you can specify, without a price, is the shape of the rule. Included quantity, if you have one. What happens past that quantity. Whether a period is a month or a contract year. Whether unused quantity expires. Who may change the rule, and whether a change affects only new usage or also usage you have already counted. Those are sentences. They are not a rate. Write the sentences first. The rate has somewhere honest to sit afterwards.

#Meter, unit, rating rule, invoice

Four lines, in this order. Teams that start with the invoice and hope the meter will become obvious spend the project reconciling.

The meter. What you count. API calls, records processed, agents invoked, environments, or something narrower that matches the contract. One product can have more than one meter. Each meter needs a source system that emits the count, an identifier for the customer, and a clock. If two systems can emit the same event, you will double count unless one of them is the source of record. Name that source. "Both, and we will deduplicate later" is how finance loses a week.

The unit. The quantity the contract speaks. Calls, thousands of calls, gigabytes, hours. The meter may emit a finer grain than the unit. Say how you round, and in which direction, and who agreed. Rounding is a commercial term. Engineers should not pick it because a data type made it easy.

The rating rule. The sentence that turns units into money. It references a price you have already decided, a period, and the included quantity. If the sentence is not finished, rating is not ready to implement. Building the pipeline first does not finish the sentence. It gives you a precise charge against an unfinished rule, which is worse than a blank invoice.

The invoice owner. A person, not a committee, who accepts that the rated amount is what you will bill. They can send a charge back. A meter that writes straight to an invoice, with no owner, will bill your mistakes at the speed of the integration. Give the owner a review queue for the pilot. Shrink the queue only after the counts have matched an independent tally for a full period.

Agentforce Revenue Management is the aim, so the design should say which of these four lines you expect that product to hold, and which still live in the source system for now. "It will all be in Revenue Management" is not an answer you can test. "The meter stays in the product, the rated total is reviewed by this person, and the invoice is raised here" is an answer you can test.

#What "migration" can honestly mean

"m3ter data migration to salesforce quote" is a reasonable phrase only if you already have m3ter history: meters, rated periods, customer maps, and invoices already issued. If you do, the migration question is which history must remain explainable. A customer who disputes last quarter's usage will ask for the count. If you load only the total and drop the events, you cannot answer them. Scope the grain you will keep.

If you do not have that history, you are not migrating. You are defining meters for a pricing motion you may now point at Agentforce Revenue Management. Say that in the first paragraph of the statement of work. A partner template titled migration services should lose that title before it gathers line items for a source system you do not run.

Pre-close exports, if they exist, need an owner and a retention clock like any other billing record. They are financial data. They do not belong in a shared drive named "old m3ter" with the whole revenue team as editors. Name who may open them. Name when they can be destroyed. If no export exists, write "none" so the gap is visible.

#Cost is the scope list

No price per call lives on this page, and no implementation fee either. Ask for a quote against this list.

• Each meter, its source of record, and the customer identifier on the event.
• The unit, the rounding rule, and the person who agreed the rounding.
• The rating sentence, including included quantity and the period, without a sample rate sneaked in as illustration.
• The invoice owner, and the review step that stays in place through the first full period.
• How missing usage is handled: delay the invoice, bill zero, or hold for a person. Pick one.
• How a dispute replays the count. Grain you keep, and for how long.
• Pre-close history, or an explicit none.
• What you will not do in the first release: a second meter, a second rounding style, an automatic write to amount fields a seller also edits.

Missing usage deserves its own sentence because it is where projects pretend. Events arrive late. A day is absent. A customer identifier does not match. The temptation is to estimate, so the invoice goes out on the usual date. Estimating usage you did not meter is inventing a bill. Choose delay, zero, or a human hold. Write it down. An estimate is not a fourth option unless finance and legal have accepted it as a rule, in words, with a limit.

#The test for a partner

"Best m3ter salesforce integration agency" asks for a winner. There is not one that is true for every rate card. Test the firm on your meters.

They ask what you count before they talk about objects. They refuse to suggest a price per API call. They will not put a sample rate in the proposal. They name the source of record and the invoice owner as people. They can describe, on a late event, whether the invoice waits. They know the work is aimed at Agentforce Revenue Management and they do not tell you the feature is already in every org. They can say "you are not migrating" if you have no history, and they can strike the migration title from their own template.

A hired m3ter Salesforce consultant who opens by configuring a price book has started from the wrong end. The price book is where a finished rule is stored. You do not have a finished rule yet. An implementation partner who cannot leave a workshop with the four lines written, even as blanks you still owe, is not ready to build. Blanks are useful. Fake numbers are not.

#What finance should see before build

#The first period is a reconciliation, not a launch

Run one full billing period with the review queue still in front of a person. Pick a handful of customers that finance already understands, including one whose usage is bursty and one whose identifier has been wrong before. At the end of the period, compare the meter's total with an independent tally from the source of record. The independent tally is a report a person can rerun, not a memory of what the dashboard showed on the day.

Write the differences down without fixing them in silence. A late event, a duplicate emitter, a rounding surprise, a customer mapped to the wrong contract. Each one is a rule you either have or do not have. If the rated amount moved because someone adjusted a row to make the invoice match a spreadsheet, you do not have a meter. You have a spreadsheet with extra steps. The invoice owner should be able to point at the rule for every adjustment.

Do not add a second meter in this period. A second meter doubles the mapping work and gives the team a way to hide a failed first meter inside a broader story. Finish one count that finance will sign. Then talk about the next unit. Agentforce Revenue Management can wait for that signature. Pointing the aim at a product name does not shorten the reconciliation.

Keep the rated output beside the source count for that first period, in a place finance can open without asking engineering to rerun a job. If the two numbers disagree, the invoice waits. Agreement is not a screenshot of a dashboard taken on the morning of the bill. It is a comparison someone else can repeat. Write the name of that person next to the invoice owner. They can be the same person only if you accept that nobody else will check the work.

A customer-agent platform is a different 2026 close, and it will attract the same habit of assuming every org already includes the product. Keep the briefs apart. The agent question is Fin, formerly Intercom.

#The other searches

The project quote is on m3ter implementation cost. That page does not print a figure. Who bought the company is on what happened to m3ter. The connector is on integrating m3ter with Salesforce. Whether to move is on should I migrate from m3ter. The customer fee is on m3ter licence cost. Who to hire is on hiring for m3ter. This page does not rank an agency.