adsoraDefine eligible reasons in the agreement
Write the project and delivery criteria first. The credit policy can then refer to a specific mismatch: an excluded project, an out-of-area property or a required field that failed the agreed standard. Avoid terms such as qualified or valid without saying what the reviewer will check.
Agree the request window, the evidence required, the response timeframe and how approved credits appear in billing. If a record passes a technical acceptance check but later proves outside the agreed project scope, state how that review is handled. The website’s general description should not be the only place a buyer looks for the rule.
Separate the problem from the requested adjustment
| Observed event | What to inspect |
|---|---|
| Malformed delivery | Request fields, receiving specification and response |
| Out-of-area project | Service location and territory rules at delivery |
| Wrong project type | Captured request and accepted project definition |
| Possible duplicate | Matching rule, lookback period and source identity |
| No answer | Logged contact attempts; eligibility depends on the agreement |
| No sale | Sales outcome; eligibility depends on the agreement |
These are review categories, not a list of Adsora’s promised credits. The commercial agreement determines eligibility. A no-answer outcome does not by itself identify a source error, while a seller should still be able to investigate an agreed contact-data issue with the relevant evidence.
Make a request easy to investigate
Include the source lead ID, buyer transaction ID, delivery date, selected reason and a short description of the mismatch. Refer to the relevant rule and its version if the coverage or project definition changed. Use the approved private channel for supporting records rather than pasting homeowner information into a broad email thread.
Keep the description factual. “Homeowner requested a roof repair; campaign accepts replacement only” tells the reviewer what to compare. “Sales says these are terrible” does not. If the evidence is incomplete, mark the request as needing information and name who can supply it.
Keep request, review and credit separate
A submitted request is not an approved credit. Track requested, under review, approved, declined and resolved statuses with timestamps. Retain the original transaction when a credit is approved, then record the adjustment against it. That lets finance reconcile the invoice without changing the sales team’s history.
If the supplier declines a request, preserve the reason and the rule used. Define an escalation path for disputed interpretations. A small set of repeated disagreements may show that the buying definition needs clarification before more traffic is accepted.
Use credit patterns to fix the program
Group requests by trade, source, branch and reason. Repeated territory mismatches suggest a coverage or address-mapping issue. Repeated missing fields suggest an acceptance or capture problem. A branch with a large unworked queue needs a separate follow-up review even if it also submits credit requests.
Record the correction and its effective date, then compare later records against the same rule. Bring your required review terms to the Adsora buying discussion so both teams can agree on the program before launch.