Handle a client query

Who does this: Payroll Executive · Payroll Lead · Platform Admin When: A client emails, messages, or calls outside the portal asking "why is X", "can we add Y this month after submitting", or "is this normal"Result: The query is logged on the cycle, routed to the right next-step (data change, override, escalation, or simple answer), and the audit trail tells the next reader exactly what happened.

The portal handles the standard cases: intake, request-info, approval, revision-request. This runbook covers the messy middle — the off-platform question that arrives by email, WhatsApp, or call. The risk here is that you answer the question and never log it; six months later, an auditor or the next payroll executive can't reconstruct why a cycle moved the way it did.

The rule of thumb: every change to platform data must be triggered through the platform, never by direct edits. The audit log only knows what the platform did.

Before you start

• [ ] You can identify the client and the cycle the query is about.
• [ ] You have the actual text of the client's question — paraphrasing into a cycle note loses nuance an auditor may need later.

Steps

1 — Log the query immediately

Before you do anything else, capture the query on the cycle.

1. Open Cycles in the staff dashboard sidebar.
2. Find the right client + cycle month and click in.
3. Open the Activity log (top-right "More actions" menu → Activity log).
4. Add a free-form note: "Client query received — {channel: email / WhatsApp / call}. Question: {paraphrase or quote}. Sender: {contact name and email}. Timestamp received: {when}."
5. If the email or message attachment is relevant, upload it as a cycle file under file kind OTHER so it's preserved in the same place as everything else.

This step is non-negotiable even if you can answer in 30 seconds. The platform's audit log is the single source of truth for the cycle's history.

2 — Triage into one of four buckets

If the question is…	It's a…	Go to step…
"Please add this employee / change this figure"	Data change request	Step 3a
"Why is the CPF rate X / why is bonus prorated this way?"	Process / explanation question	Step 3b
"This figure looks wrong" and the cycle is already in CLIENT_REVIEW	Effectively a revision request	Step 3c
"Something is broken / I can't log in / the link doesn't work"	Bug or access issue	Step 3d

3a — Data change request (cycle still in flight)

If the cycle is at INTAKE_IN_PROGRESS, SUBMITTED, ACTION_REQUIRED, or READY_FOR_EXPORT:

1. Don't just update the submission item from your side — that loses the client-attestation chain. Instead, click Request info from client on the cycle page and explicitly ask them to add or amend through the portal. See Request info from a client.
2. Exception: if it's a tiny correction (typo in employee name, date format) and the client confirmed it in writing, you can edit the submission item inline; the audit log captures who edited what, paired with your note from Step 1.

If the cycle is at EXPORTED or beyond, treat it as a revision request — go to Step 3c.

3b — Process / explanation question

These are the easy ones. The client doesn't want anything changed; they want to understand.

1. Answer them — by email or call — referencing concrete inputs from the cycle so they can verify themselves.
2. Add a follow-up note in the Activity log: "Replied to client at {timestamp} explaining {summary}. Resolution: no action required."
3. Mark the query closed in your own task tracker. There is no portal status for "client question answered" — the activity log entry is the closure record.

3c — Effectively a revision request

If the cycle is in CLIENT_REVIEW and the client's off-platform message is functionally "I want a revision", push them back into the official flow rather than silently re-doing things:

1. Reply to the client: "I'll process that as a revision request. Could you click Request revision on the approval portal so the platform records it formally? I've started looking at it on my side already."
2. While you wait, draft your fix. When the client clicks Request revision in the portal, the cycle moves to REVISION_REQUESTED and you continue from Handle a revision request.
3. If the client refuses to use the portal: open CLIENT_QUERY_OPEN on the cycle (header → Resolve Query is the inverse — there's no "open query" button in the cycle UI directly; the off-platform path is to leave the cycle in CLIENT_REVIEW, log the question, and proceed via the relationship manager). Document everything in the Activity log.

3d — Bug or access issue

If the client says they can't log in, the link doesn't work, or something on the portal is broken:

1. Magic link expired? → The magic link expired. You can re-send a fresh invitation from the cycle page.
2. Email never arrived? → Verify an email was sent, then Client didn't receive the email.
3. Portal page is broken → escalate to engineering with the cycle ID and the client's exact steps. Don't manually update database state.

How to know you handled it correctly

• The Activity log has at minimum two notes: the inbound query and the outcome.
• If a data change was needed, the change was made through a platform action (intake edit / Generate export / Override issue) rather than direct database manipulation.
• If the question was process-only, the client got a reply and the resolution note is on the cycle.
• The next staff member opening this cycle a month from now can reconstruct what the client asked, what you did, and why.

WARNING

Never edit the database directly to satisfy a client query. The audit log only captures actions taken through the platform — a direct edit is invisible to it, which means you become the only person who knows the change happened. If the cycle later goes wrong, neither the relationship manager nor the auditor can trace it. Always go through the UI.

Common situations

If you see…	It means…	What to do
Client asks for a change after they've already approved	The cycle is in APPROVED / FINALIZED / CLOSED; revision is no longer in the workflow	Escalate to Payroll Lead — for a true error, they can recover from a mistake by opening a corrective off-cycle. For minor variances, document the discrepancy and address it in next month's cycle
Client wants you to add a record on their behalf without re-doing intake	They want speed, you need attribution	Get explicit written confirmation, capture in Activity log, edit inline. Decision is yours — bias toward making them use the portal when the change is non-trivial
Client query is actually about a different cycle than they think	Easy to mis-identify when months overlap	Confirm cycle month before doing anything. The Activity log note also names the cycle for future readers
You're not sure if the question warrants a revision-request or just an answer	Default to answer first, escalate only if the answer doesn't satisfy	Many "queries" close with a one-line clarification

Related runbooks

• Request info from a client — the formal portal-driven follow-up
• Handle a revision request — for the in-portal version of this flow
• Override a blocking issue — when the client's concern is genuinely not an issue
• Recover from a wrong action using the audit log
• Verify an email was sent
• Export an audit log for an external auditor — when a query becomes audit evidence