How to Track a Submission You Do Not Control
Why this matters
Once a claim leaves your hands you own none of the process and all of the customer relationship. The program will not call you when something stalls, will not tell you a reviewer has questions unless it sends a request you might not see, and will not distinguish between a claim you forgot about and one it lost. Meanwhile the customer has exactly one number to call, and it is yours. Tracking is not administrative tidiness. It is the only thing standing between a normal processing delay and a customer who believes you did nothing.
The steps below are ordered by what skipping each one costs you, worst first, rather than by the sequence you perform them in. If you only ever do the first two, do those two.
You are tracking a state machine you cannot see inside
A claim is always in exactly one of five states, and your entire tracking job is knowing which. You cannot observe the state directly. You infer it from evidence you hold, which is why the evidence matters more than the checking.
| State | Evidence you are in it | What you owe the customer |
|---|---|---|
| Submitted | A confirmation reference and a submission date | The fact of submission, the date, and the program's own published window |
| In review | An acknowledgement, a portal status, or simply time passing without a request | Nothing new unless they ask; then, the state and the marker date |
| Information requested | A request from the processor, with a response deadline | Whatever you need from them, immediately, with the deadline named |
| Approved, pending payment | An approval notice or portal status change | That it cleared and that payment timing is still the program's |
| Paid | Funds received and matched to a claim | Confirmation, and the close of the conversation |
Rejected is the exit, not a state on this board, and it moves to a different procedure the day it arrives.
The state that hurts is the middle one. Information requested is the only state carrying a clock you can miss, it is usually the shortest clock in the whole process, and it is the state you are most likely to be in without knowing.
Steps, ordered by what skipping each costs you
1. Capture the confirmation reference in the same session as the submission. Highest cost of omission on the list, by a wide margin. Without it you cannot chase, cannot prove you filed, and cannot distinguish "in review" from "never arrived." A claim with no confirmation reference has one remedy, which is to file it again from scratch, and that remedy expires with the filing deadline. Everything else on this list is recoverable. This one is not.
2. Record the response deadline and the cure window at submission time, not when you need them. Write down what the program says about how long you get to answer an information request and how long you get to correct a rejection. Skip it and you will read those rules for the first time on the day the clock is already half gone, which is also the day you are least able to act on them.
3. Put a chase date on every claim the moment it is submitted. Skip it and claims age invisibly. There is no natural event that reminds you a claim is slow, because slowness produces silence, and silence looks exactly like normal processing. Set the date from your own measured payment history rather than from the program's brochure; if you have fewer than 10 paid claims with that program, start at 12 weeks and replace it with your own nine-in-ten mark once you have the history.
4. Route all processor mail and portal notifications to a shared box. Skip it and an information request with a short deadline sits in one person's inbox while they are on vacation, and a live claim dies of nothing. This is the cheapest step on the list and the one most often skipped, because the coordinator who set up the account did not think of themselves as a single point of failure.
5. Tell the customer the state, never the outcome. Skip it and you inherit the program's timeline as a promise you made. "It was submitted on the ninth, the program's window is what it is, and I will contact them if it passes twelve weeks" is a status. "It should be about eight weeks" is a commitment you cannot keep, made about a process you do not run.
6. Reconcile paid claims off the board weekly. Skip it and the board fills with claims that already paid, which makes the open count wrong, which makes the late count wrong, which is how a board loses credibility. A board nobody trusts gets ignored inside a month, and then you are back to step one having lost everything above it.
Set the chase date from your own history
The number a program publishes is a service target, and it is generally the number that describes a claim with no complications. Your own history includes the complications, which is why it is the number that predicts.
The mistake is to set the chase date at your median. By definition, half your claims run past their median, so a chase date at the median generates a chase call on half your claims and most of those calls learn nothing. Set it at the mark where nine in ten of your claims have paid. Then a chase date arriving means something is genuinely unusual, and the coordinator treats it that way instead of working through a list of false alarms. See the companion reference on the timeline between submission and payment for how to build that number from your own claims.
What to say on the chase call, and to whom
Call with the confirmation reference, the submission date, and one question: which check is this claim sitting at, or what is its current status in your system. That question is answerable by a first-line clerk in one sentence. "Why is this taking so long" is not answerable by anyone you can reach, and it invites boilerplate.
Three things to establish before you hang up, in this order. Whether the claim is in the system at all under that reference. Whether anything has been requested from you that you did not receive. And what the program considers the current state, in their words, so you can write it on the board rather than paraphrasing it.
Escalate past the first-line channel at about one and a half times your chase interval, and escalate on a specific finding rather than on frustration: a claim not found under its own confirmation reference, a request the program says it sent and you never received, or a state that has not moved across two contacts. Escalation without a finding just resets the same conversation one level up.
An aging board on one Monday morning
Ages below are weeks since submission. The shop's chase mark for this program is 12 weeks, built from its own paid history.
| Age bucket | Open claims |
|---|---|
| 0 to 4 weeks | 7 |
| 5 to 8 weeks | 9 |
| 9 to 12 weeks | 4 |
| Over 12 weeks | 2 |
Twenty-two open claims. The instinct is to look at the 4 sitting in the 9-to-12 bucket, because they feel old. They are not late. The chase mark is 12 weeks, and nothing in that bucket has crossed it, so touching them costs coordinator time and produces nothing. Only 2 of 22, about 9%, are actually late, and both of them are real.
The first late claim has no confirmation reference on its row. That is not a slow claim, it is an unknown claim: nobody can tell whether it was ever received. Its only path is to check whether the filing deadline is still open and, if it is, resubmit. If the deadline has closed, it stops being a tracking problem and becomes a conversation with the customer and a decision about who absorbs it.
The second late claim is sitting in information requested. The request arrived three weeks ago in a personal inbox, which is step 4 failing exactly as advertised, and its response deadline is close enough that it goes to the front of the queue ahead of everything else on this board, including the two brand-new claims that would take ten minutes each.
Two findings worth separating. The board did its job: it surfaced two real problems out of twenty-two claims and told the coordinator not to spend the morning on the four that merely looked old. And the board also revealed its own two upstream failures, one missing confirmation reference and one unshared inbox, both of which are process defects rather than claim defects, and neither of which the coordinator can fix by working harder on this board.
When to stop chasing
Not every claim ends in a payment, and a claim that will never pay still costs coordinator time every week it stays open. Close it, in the log, with a reason, when any of these is true: the program has denied it and the cure window has closed; the filing deadline has passed on a claim with no confirmation reference; the program has confirmed funds are exhausted for the period and offers no waitlist; or the customer has withdrawn.
Closing is not giving up quietly. Every close produces one call to the customer explaining what happened in plain language, and, where the failure traces to a link your shop owned, a decision about making them whole under whatever policy you set before any of this happened. Deciding that in the moment, claim by claim, is how shops end up with three different answers for three customers who talk to each other.
References
- The current published terms of the specific utility, manufacturer or state program, which set the response deadline, the cure window and the filing deadline referenced throughout
- See related: The Rebate Submission SOP; The Timeline Between Submission and Payment; How to Handle a Rejected Rebate Claim; Explaining Rebates and Incentives Without Overpromising