Information Requests and the Chase Loop That Actually Closes Them

An information request is the firm asking the client for something it needs in order to proceed: a document, a figure, a confirmation, an introduction. Across most engagement types this is the largest single source of schedule slippage, and it is the one firms are least able to evidence, because the asking usually happens in email and the waiting is not recorded anywhere.

The consequence shows up at the difficult conversation. The engagement is three weeks late, the client believes the firm was slow, and the firm believes it was waiting. Without a register, that argument is decided by whoever is more confident. With one, it is decided by the dates.

Splitting the register by who holds it

The first useful move is to stop treating the request list as one list. What a mobilisation meeting actually needs to know is what is sitting with the client and what is sitting with the firm, because those are two different problems with two different owners.

Requests sitting with the client need chasing and escalation. Requests sitting with the firm, typically something received and not yet reviewed, need capacity. Reporting them together produces a number that nobody can act on, and it usually flatters the firm, because a large pile of unreviewed submissions looks like client delay.

The reporting period is not the due date

This distinction is small and saves a recurring argument. A request for March figures raised in July has a due date in July and a reporting period of March. Systems that carry only a due date make that request appear four months overdue, and the client, who received it a week ago, is understandably annoyed.

Carrying both means the register can say what a request is about and when it is needed, separately, and ageing can be measured from when it was actually asked. It also lets the firm see the pattern that matters at closure: which periods habitually arrive late, which is a pricing input for next year.

The states a request moves through

• Raised, and not yet sent. A draft list being assembled is not a request the client owes anything against.
• Sent, at which point the clock starts and the client can see it.
• Chased, with a count, because the third chase is a different conversation from the first.
• Escalated, which should follow whatever ladder the engagement agreed rather than being invented per request.
• Answered, which is not the end: what came back is accepted, sent back with a reason, or recorded as partly received with the gap named.
• Not applicable, with a written reason, because a client is entitled to say a request does not apply and the firm needs that on the record.
• Withdrawn, when the firm no longer needs it, which is different from deleting the request the client already answered against.

Why the reason has to be captured at the moment

Every one of the terminal states above carries a reason, and every one of those reasons is worth almost nothing if it is written later. Partly received with the gap named is useful the day it happens and a reconstruction three weeks afterwards. Not applicable with a reason is a defensible record on the day and an assertion later.

This is the strongest practical argument for the client answering in the portal rather than by email. The reason is required at the point of the action, from the person taking it, and it lands on the record attached to the item rather than in a thread somebody has to find.

Escalation that is agreed rather than improvised

Escalation works when it was agreed at mobilisation and follows a named ladder: the working contact, then their manager, then the sponsor, at stated intervals. It fails when it is improvised, because improvised escalation feels personal to the recipient and the firm avoids it until the delay is severe.

Agreeing the ladder in advance converts escalation from a confrontation into a process. When the second chase automatically copies a named person because that is what both sides agreed in week one, nobody has made a decision about a relationship.