Dialbrew for sales-as-a-service providers

What this gets you

• Meetings priced as products, per client, with a customer price and a rep commission
• Invoices generated from the billable set rather than assembled by hand
• A frozen price on each billing record so sent invoices stay reproducible
• Credits for no-shows and cancellations applied by a stored policy
• Clients able to verify what they are paying for, themselves

Selling an outcome, not hours

A sales-as-a-service business sells a unit — usually a qualified meeting — at a price. That sounds simpler than selling hours, and operationally it is harder, because the unit has to be defined precisely enough to bill for and to dispute.

What counts as deliverable? What happens when the prospect does not turn up? What if they reschedule twice and then attend? Who decides, and does the client agree? Every one of those questions is a billing question, and answering them inconsistently is what erodes a productised service.

Defining the unit

Products are where the definition lives. Each client has products; each product carries a customer price and an SDR commission. One is the default. Products are archive-only, never deleted, so a historical booking always resolves to the product that priced it.

A completed booking generates one commission row — enforced by a unique database constraint on the booking — and joins the billable set that becomes the client’s invoice. Because both come from the same row, the margin on a meeting is a derived fact rather than something you compute separately and hope matches.

The no-show question, answered once

This is the question that decides whether a productised service holds together.

Dialbrew records held, no-show and no-show-with-reschedule as distinct outcomes, and a compensation matrix resolves each case: what the rep keeps, what the client is credited. The policy is stored, so the same situation resolves identically every month regardless of who is closing the books.

Just as importantly, the client sees the resolution in their own portal. A credit that appears automatically is a non-event. A credit the client has to ask for is a renewal risk.

Invoicing that runs itself

Billable bookings roll into a billing record with a lifecycle: creating → ready → invoiced → sent/paid. Dialbrew pushes the record to Procountor and polls it for status, so the state of an invoice is visible in the same system as the work that produced it.

The price is frozen onto the billing record when it is created. This matters more than it sounds: change a product price next quarter and last quarter’s invoices still reproduce exactly, because they were never looking the price up live.

The shared definition of “billed” is deliberate too — a record in sent or paid counts as invoiced; one in creating, ready, failed or invoiced (a Procountor draft) does not. The client portal and the compensation logic both read that one definition, so they cannot disagree about whether a meeting has been charged for.

Proving delivery

The client portal shows their meetings with outcomes, their scheduled reports, and their billing including which meetings sit on which invoice at which frozen price. Calls can be recorded and transcribed, so where a dispute is about what was actually said, there is a record rather than two recollections.

Scope

Dialbrew prices, tracks and invoices the work. It does not source your leads or send your email, and it is not your clients’ CRM — it pushes bookings into theirs. If the thing you are buying is top-of-funnel volume, this is the wrong layer.