This article shares practical collections-desk habits for Philippine money lenders and small MFIs for educational purposes. It is not legal, regulatory, or financial advice. Align any promise-to-pay follow-up rules with your compliance lead and current written policies before you change escalation steps. Demo peso amounts below are illustrative only—not performance claims or repayment guarantees.
A borrower says “bayad ako bukas.” The officer nods, hangs up, and the promise vanishes into a group chat by Friday. A promise to pay follow-up board fixes that: every verbal or SMS PTP gets a dated row, an owner, a re-check time, and an outcome column—so broken promises escalate on purpose instead of dying in a notebook.
This guide is for Philippine microfinance and small multi-branch lending desks that still live on phone calls, field visits, and branch walk-ins. You will get a morning PTP board (columns + aging buckets), a three-step broken-promise escalation ladder, a worked illustrative ₱ failure mode when undated PTPs evaporate, the traps that fake “followed up,” a decision framework, and a soft note on where a lending LMS such as PesoLend can hold the same diary in notes, tasks, and calendar dues—without inventing a branded PTP Module or collections BI suite.
What promise-to-pay follow-up actually means
It is not “officer heard a promise and moved on.” It is a written (or LMS-stored) commitment with four hard fields:
- Promise date and amount — what the borrower said they will pay, and when
- Channel — voice call, SMS, branch visit, or field visit (whatever your policy allows)
- Owner — named officer or desk who must re-check, not “collections team”
- Outcome stamp — kept / partial / broken / rescheduled / unreachable, with timestamp
If a PTP can sit without a next re-check date, you do not have follow-up. You have a rumor. That distinction matters when supervisors ask “how many promises broke this week?” and the answer is a shrug. Early DPD habits still matter—pair this board with your week-one delinquency playbook—but today’s focus is turning each verbal PTP into dated desk work before the dial list starts.
Who this is for — and who should skip
Build this ritual now if: collectors take verbal PTPs daily; promises live in chat threads or personal notebooks; Friday cash-in surprises the branch manager; officers mark “followed up” without an outcome stamp; or broken PTPs never trigger a named next action.
Deprioritize if: every PTP already lands as a dated task with owner and outcome on the same loan file, and supervisors review broken-promise aging every morning. Your next bottleneck is probably retention-safe tone on hard accounts—see collections that protect cashflow without killing retention—or holiday ownership when the branch is closed via Sunday and holiday desk coverage. Guarantor contact quality before release is a different gate; keep that on your guarantor contact recheck, not on the PTP board.
Why verbal PTPs vanish by Friday
Most vanish for process reasons, not bad borrowers:
- No row, no date. The promise never leaves the call recording or a sticky note that gets thrown away.
- Owner is “the team.” When everyone owns the re-check, nobody dials at 9:00 a.m.
- Outcome is binary hope. Officers only track “paid / not paid,” so partials and reschedules look like silence.
- Aging is invisible. A PTP that broke two days ago sits next to one that is still due this afternoon.
- Escalation is improvised. Broken promises jump to field visit or legal talk without a ladder, so officers avoid logging breaks.
A morning board with aging buckets fixes visibility. Training cannot outrun a desk that treats “bayad bukas” as closed work. Soft LMS flags before DPD-7 can still help triage pressure—see early warning signals before DPD-7—but they do not replace a dated PTP diary with a human owner.
Original element: morning PTP follow-up board (columns + aging)
Use this as an ops acceptance board—paper, whiteboard, shared spreadsheet, or LMS notes/tasks. This is design advice for your diary, not a claim that a branded “PTP Module” or collections BI suite ships as a separate SKU.
Board columns (one row per open PTP)
| Column | What to capture | Pass rule |
|---|---|---|
| Account | Loan ID + borrower short name | Matches the live loan file, not a nickname-only chat |
| Promise | ₱ amount + promised date/time | Both fields filled; “soon” is rejected |
| Channel | Call / SMS / branch / field | Matches how the promise was taken |
| Owner | Named officer or desk seat | One human, not a group chat name |
| Re-check due | Next action datetime (Asia/Manila) | Always future-dated relative to promise date |
| Outcome | Open / kept / partial / broken / rescheduled / unreachable | Only “kept” or closed partial clears the row |
| Next action | What happens if broken | Must name step 1–3 on the ladder below |
Aging buckets (sweep before first dials)
| Bucket | Definition | Morning action |
|---|---|---|
| Due today | Re-check falls on today’s shift | Top of dial / visit list; owner confirms by cut-off |
| Overdue 1 day | Re-check missed yesterday | Mark broken or reschedule with manager note; do not leave “open” |
| Overdue 2+ days | Still open without outcome | Force ladder step 2; supervisor reviews before noon |
| Broken this week | Outcome = broken in last 7 days | Count for Monday huddle; check repeat breakers |
| Kept (archive) | Paid as promised or closed partial | Move off live board; keep stamp on loan history |
Daily sweep checklist (10–15 minutes)
- Pull every open PTP with re-check ≤ today into Due today.
- Move any row with re-check < yesterday and no outcome into Overdue; assign ladder step.
- Confirm each Due-today row has a live owner on shift (handover if the named officer is out).
- Close kept/partial rows only when the repayment (or agreed partial) is posted—pair cash proof with collection receipt discipline.
- Log broken-this-week count for the branch huddle; watch for the same borrower breaking twice.
Print the columns beside the dial desk for one week, or mirror the same fields as LMS tasks on the loan. Either way, supervisors must see aging without opening twenty chat threads.
Broken-promise escalation ladder (three steps)
When outcome = broken (or overdue with no honest reschedule), escalate in order. Skip steps only with a named manager reason code.
- Step 1 — Same-day re-promise with tighter stamp. Owner re-contacts; new promise must include amount, datetime, and channel. Old row closes as broken; new row opens with re-check no later than next business morning. Cap: one same-day re-promise per account per week unless manager overrides.
- Step 2 — Supervisor-owned contact + channel change. If Step 1 breaks or borrower is unreachable, supervisor owns the next attempt within 24 hours and usually switches channel (e.g., call → field visit or branch invite). Document who spoke and what was agreed.
- Step 3 — Formal desk hold path. After two breaks (or one break on a larger ticket per your policy), apply your written path: field visit with receipt discipline, guarantor notify if policy allows, or referral to your recovery queue. This is policy work—not AI scoring, not an early-warning product SKU.
The ladder exists so officers are not inventing legal threats on Tuesday and forgetting the account on Thursday. Soft tone still applies; cashflow protection without burning retention is the north star.
Worked example: illustrative ₱ failure mode when verbal PTPs are not dated
Structure only—illustrative numbers for a market-stall borrower, not a live case or performance claim.
Happy path (demo): Tuesday 4:10 p.m., collector Ana takes a voice PTP: ₱3,500 on Wednesday by 11:00 a.m. Asia/Manila via branch cash. Board row opens—Loan 10482, promise ₱3,500 Wed 11:00, channel=call, owner=Ana, re-check=Wed 11:30, outcome=open, next action=Step 1 if broken. Wednesday 11:25 Ana confirms partial ₱2,000 posted with receipt; outcome=partial; new PTP row for remaining ₱1,500 due Thursday 10:00 with same owner. Thursday payment clears; rows archive as kept/partial. Supervisor’s Friday board shows zero overdue for Ana’s book.
Failure mode (demo): Same Tuesday call, but Ana only texts the group chat “10482 bayad bukas.” No board row. Wednesday market is busy; nobody re-checks. Friday the branch manager expects ₱3,500 float that never arrives. The borrower now says “sa Monday na.” There is no broken stamp, no Step 2 owner, and no aging bucket—just a cold account and a surprised cash position. Contrast: with the board, Wednesday 11:30 auto-moves the row to Overdue 1 day, Ana must stamp broken or reschedule, and Step 1 forces a tighter Monday stamp instead of hope.
That failure mode is why re-check due exists. “Bayad bukas” without a Wednesday cell on the board is how verbal PTPs vanish by Friday.
Traps that fake “followed up”
- Chat-only PTP. If the promise lives only in Messenger or a group thread, it will not survive shift change—same orphan risk as a bad loan officer exit handover.
- Outcome = “called.” Dialing is activity, not outcome. Stamp kept / partial / broken / unreachable.
- Eternal reschedule. Three reschedules without a break stamp is a soft skip of the ladder.
- Owner = branch name. “QC desk” is not a human who can miss a re-check.
- Closing the row on promise, not payment. Archive only when cash (or documented waiver) hits the loan.
- Skipping Step 2 because the officer “knows the borrower.” Familiarity without a supervisor stamp is how repeat breakers hide.
Decision framework: keep open, stamp broken, reschedule, or escalate
| Situation | Do this | Do not |
|---|---|---|
| Re-check time not yet reached; borrower silent | Leave open; dial at re-check | Mark kept early |
| Partial cash in, balance promised later | Stamp partial; open new PTP for remainder | Leave one fuzzy open row |
| No contact by re-check +1 business day | Stamp broken or unreachable; start Step 1/2 | Quietly delete the row |
| Borrower asks to move date before due | Reschedule once with new re-check; note reason | Stack unlimited reschedules |
| Second break in seven days | Step 2 or 3 per policy | Another casual “bukas” in chat |
Where a lending LMS helps (claim-safe)
You can run the board on paper. An LMS helps when the same diary must survive multi-branch handoffs, staff roles, and audit questions. On a Day-20 Must framing, look for:
- Loan notes / tasks with due dates and owners (calendar dues)
- Repayment posting so “kept” ties to real cash, not a checkbox
- Staff/roles so the owner field is a real user
- Reports / PAR views so broken-promise pressure is visible beside delinquency—not a separate “collections BI suite”
- Reminder stubs/hooks if you use them—desk habit first; do not claim live carrier SLAs or native live mobile rails
- Maker-checker and ops dashboard shell for money movement and desk visibility
PesoLend is built as a Philippine-ready lending LMS along those lines. Soft CTA: try the workflow in the app at pesolend.com/app/login. This article does not invent a PTP Module, AI early-warning SKU, float/treasury module, renewal engine, guarantor+e-sign pack, offline field app, or GCash/Maya live rails.
FAQs
Do we need software on day one?
No. A whiteboard or shared sheet with the columns above beats undated chat promises. Move to LMS tasks when multi-branch ownership and audit trails matter.
What if the borrower always pays a day late?
Stamp outcomes honestly. Chronic late-but-paid may be a product or schedule issue, not a PTP board failure—fix the kept/partial history rather than pretending every late is a surprise.
How is this different from DPD buckets?
DPD ages the unpaid schedule. The PTP board ages promises. An account can be DPD-3 with a kept PTP for a partial, or DPD-0 with a broken PTP that never posted. Run both.
Can we auto-escalate with AI?
Not as a live claim here. Use human-owned ladder steps. Any future scoring or early-warning features should be labeled roadmap until they ship in the app you actually run.
What to do next
Tomorrow morning, before first dials: draw the seven columns, sort open promises into Due today / Overdue / Broken this week, assign one human owner per row, and run the three-step ladder on anything overdue without an outcome. When the desk outgrows paper, park the same fields in your LMS notes and calendar dues—and keep the CTA simple: log in to PesoLend when you are ready to make the diary survive shift change.