Pay Per Result: Why PTS AI Only Gets Paid When You Get a Meeting

Here's the short version. PTS AI charges only for results.

A result is one of two things: a booked meeting or a reactivated customer.

Nothing else gets billed. Not calls. Not minutes. Not seats. Not months. And there's nothing to pay up front.

You start with one branch. In 14 days, every reachable customer on that branch's list gets called, and the interested ones are transferred live to that branch while it's open.

No results means nothing to pay.

The amount per result isn't on the website. We quote it on the call.

The rest of this article covers why we price it this way, what it asks of you in return, and what you have at day 14 either way.

Why you shouldn't carry the risk of a vendor's slide deck

You've sat through the demo. You know how it goes.

A vendor plays a smooth recording of an AI having a nice conversation. There's a chart that goes up and to the right. Then there's an invoice, due before a single one of your customers has heard a single call.

That's a bad deal for a lender. Not because the vendor is lying. Because a demo proves the AI can talk. It doesn't prove the AI can put a borrower on the phone with your branch on Main Street on a Wednesday at 10 a.m.

That depends on your list, your numbers, your branch hours, your transfer lines and your CRM. Nobody can show you that in a demo. You only see it with real customers.

So think about who carries the risk in the usual deal. You pay first. The vendor gets paid whether it works or not. If it doesn't work, you're the one explaining the line item to the owner.

We think that's backwards. If the calling doesn't produce results, we shouldn't get paid for it.

Calls, minutes and seats are activity, not results

Most AI calling is priced by activity. Per minute. Per call. Per seat. Per month.

Activity is easy to count. That's why vendors bill it.

But ask yourself what you'd actually brag about in the Monday meeting. Nobody says "we used 40,000 minutes last month." Minutes are a cost. They aren't the point.

Here's the problem with paying for activity. A vendor paid per minute does fine when the calls are long and go nowhere. A vendor paid per seat does fine whether anyone picks up or not. Neither one needs your branch to get a single real conversation.

So we don't bill activity. We bill the two things a lender actually wants from calling:

• A booked meeting. A borrower who's going to sit down with your branch.
• A reactivated customer. A past borrower who's back doing business with you.

That's it. If the calling produces neither, it didn't do its job, and we don't send you a bill for it.

Why pay-per-result puts us on your side of the table

Here's the plain logic.

When a vendor gets paid up front, its job is to sell you. When a vendor gets paid per result, its job is to produce results. Those are very different jobs.

Under this model, we only win when your branch gets a real conversation. That changes what we care about.

• We care about the list. So cleaning the list and verifying phones is our problem.
• We care about the caller ID. A borrower who doesn't recognize the number doesn't pick up. So a local number for the branch matters to us.
• We care about branch hours. A transfer that rings at a closed branch is worth nothing. So we only call while the branch is open.
• We care about what happens after the transfer. A transfer nobody picks up doesn't become a meeting. So we want to see where the chain breaks, same as you.

You're probably wondering what's in it for us. Simple: if it works on one branch, you'll want it on more. We'd rather earn the second branch than invoice for the first.

One more thing, so there's no confusion. Whether a borrower qualifies for a loan is your credit decision, and it should stay yours. We don't touch underwriting. We put interested borrowers on the phone with your branch. Your people and your policies do the rest.

For the full picture of the work behind a call, and what you're really paying for, read what AI calling costs a lender.

What it asks of you: one ID from the first call onward

Paying per result only works if both of us can see which call produced which result.

That's the one thing we ask for.

Here's the problem it solves. The calling system knows who it called. The phone system knows who got transferred. Your CRM knows who booked and who came back. If those don't share anything, nobody can connect a result back to the call that started it.

The fix is one ID for each customer, created at the first call and carried through everything after it.

First, the AI calls a customer from the branch's list, and the call is logged with that customer's ID.

Then, if they're transferred live, the transfer carries the same ID.

Finally, whatever happens next at your branch is recorded against that same ID.

That's how you count what calling produced, instead of guessing. And it's useful to you well beyond our invoice: it's the same chain a COO wants on the weekly board anyway. We lay that board out, branch by branch, in branch-level reporting for lenders.

How you start: one branch, 14 days

One branch sounds small. That's the point.

With one branch, you can see everything. Every transfer. Every call that rang out. Every customer who said "call me next week." Nothing hides inside an average.

With one branch, one manager owns the result. They know transfers are coming. They know who picks up.

Here's the path.

First, we clean that branch's list and set up a local number, caller ID and the voice agent. Week one walks through that in detail.

Then, the branch starts calling. Within 14 days, every reachable customer on the list gets called, and the interested ones are transferred live to that branch during branch hours.

Finally, on day 14 you have the numbers for that branch: called, reached, transferred.

What it asks of the branch is small. Someone is there to pick up during branch hours. When a borrower is on the line, they treat it like a walk-in who already said yes to the conversation. Nobody at the branch dials a single number.

Sunset Finance started small too. Their pilot ran across 10 branches. Tommy, their voice agent, placed 13,159 calls in the first 14 days and produced about 100 live transfers in those two weeks. They're now at 28 branches, with 224 live transfers and counting. Their story shows how a pilot turned into a network.

If you want the playbook for running those 14 days well, including where most pilots stall, read how to run an AI calling pilot in 14 days.

What you have on day 14, either way

Day 14 can go two ways.

It worked. Transfers landed, meetings got booked, past customers came back. You have real numbers from your own customers. You pay for the results, and you decide whether to add branches.

It didn't work on your list. Then there were no results, and there's nothing to pay. You still have the numbers for that branch, called, reached and transferred, so you can see where it broke down.

Either way, you stop guessing. And either way, you didn't pay for a slide deck.

The risk is off the table. The clock isn't.

The price risk is ours now. The risk of waiting is still yours.

People are borrowing. The Federal Reserve's G.19 consumer credit release shows consumer credit grew at a seasonally adjusted annual rate of 4.2 percent in July. The question is who they borrow from.

Your past customers already know you. But other lenders can find them too. The FTC explains that a lender sets its own requirements and asks a credit bureau for a list of people whose credit reports meet them. Your past customers can be on those lists. Every month your list sits is another month they can hear from someone else first.

One branch. 14 days. You pay for results, and only results.

If you want to hear what your borrowers would hear, leave your number on the consumer finance page. Our AI calls you within minutes and books time with our team.