Atlas
  • All-in-one
  • Solutions
  • Compare
  • Pricing
PricingGet started
  1. Atlas
  2. Guides
  3. Information Request Lists That Actually Get Answered
August 30, 2026·9 min read·information requests, data collection, delivery, client management

Information Request Lists That Actually Get Answered

The information request list is the most underestimated document in professional services. It is usually the critical path, and it is usually written in ten minutes.

Almost every engagement depends on material the client holds. The list requesting it is typically produced quickly, phrased in the firm's vocabulary, sent as a spreadsheet attachment, and then chased by email. It is also, in a large proportion of engagements, the item that determines the finish date.

Requests stall for reasons that have nothing to do with willingness. The person receiving them has a day job, the request is ambiguous, it is addressed to a group rather than an individual, and there is no visible consequence to answering late. Each of those is fixable in the way the list is written and tracked.

Writing a request somebody can complete

  • One item per row, phrased as a thing rather than a topic. "General ledger extract for the year ended 31 December, in delimited text, with account code, description, date, amount and cost centre" is completable. "Financial information" is not.
  • Name the format and the system. Clients frequently produce a formatted report when an extract was needed, which costs a full cycle to discover and repeat.
  • State the purpose in one line. A person who understands why an item is needed will often supply a better alternative than the one requested.
  • Name an individual owner, not a function. A request owned by a team is owned by nobody.
  • Give each item its own date, staged by when the work actually needs it, rather than a single date for the whole list. A list with one deadline is answered in one batch, on the deadline, at best.
  • Say what happens if it is late, in terms of the plan rather than in terms of blame.

Where the list should live

A spreadsheet attached to an email begins diverging the moment it is sent. Two versions exist within a week, one on each side, and the chase conversation becomes a reconciliation of the tracker rather than a discussion of the data.

A single shared list, visible to both parties, with a status per item and a record of who changed what, removes an entire category of work. It also changes the tone of chasing: the client can see their own outstanding items without being told, which is considerably more comfortable than receiving a weekly list of failures.

Chasing without corroding the relationship

Chasing is necessary and it is where relationships are damaged. Three habits keep it civil. Chase the individual, privately, before escalating to the sponsor. Chase with the consequence rather than the reminder, because "we will not be able to complete the analysis for the board paper on the eighteenth" is more effective and less irritating than "just following up". And when an item has been chased three times, stop chasing and raise it as a dependency in the status report, where it becomes a governance matter rather than a personal one.

The escalation should never be a surprise. Say at the outset that outstanding requests appear in the weekly report after a stated period. Then it is a published rule rather than a complaint.

Reducing what you ask for

The most effective improvement is asking for less. Request lists accumulate items because they are copied from the last engagement, and each additional item costs the client time and costs the firm chasing effort. Review the list before issuing it and remove anything whose absence would not change a conclusion.

A useful discipline is to require that each item names the analysis it feeds. Items that cannot name one are usually there because they were on the last list, and removing them makes the remainder more likely to arrive.

Keep reading

  • Deliverable Acceptance Criteria That Hold Up
  • How to Measure Engagement Health Before It Goes Wrong
  • How to Write a Weekly Status Report a Client Actually Reads
  • The First Ninety Days of a New Engagement
  • The RAID Log Explained: Risks, Assumptions, Issues and Dependencies
  • Engagement Acceptance: The Gate Before the Work Starts
  • Free PDF tools
  • The all-in-one work OS

FAQ

Questions, answered.

What makes an information request list effective?
One completable item per row naming the format and source system, a one-line purpose, a named individual owner rather than a function, a staged due date per item rather than one date for the whole list, and a stated consequence expressed in terms of the plan. Every item should name the analysis it feeds, which removes those copied from previous engagements.
Why do clients respond slowly to data requests?
Usually because the request is ambiguous, addressed to a group rather than a person, carries a single distant deadline that encourages batching, and has no visible consequence. Willingness is rarely the issue: the recipient has a full-time role and the request competes with it.
How should outstanding requests be chased?
Chase the named individual privately first, and chase with the consequence rather than a reminder: naming the analysis and the date that will be affected is more effective and less irritating. After three attempts, stop chasing and raise the item as a dependency in the status report, which was announced as the rule at the start so the escalation is not a surprise.
Should the request list be shared with the client directly?
Yes. A spreadsheet sent by email diverges into two versions within a week and turns chasing into a reconciliation exercise. A single shared list with a status per item lets the client see their own outstanding work without being told, which removes both the reconciliation and much of the friction.

Ready when you are

One workspace, not ten.

Atlas replaces the stack with one platform for tasks, projects, CRM, contracts, e-signature, PDF tools, and analytics. Start free.

Get started freeSee pricing
AtlasWork, planned itself.

The AI-native, all-in-one work platform. Tasks, projects, CRM, contracts, and analytics in one calm workspace.

All systems operational
  • SOC 2 II
  • ISO 27001
  • HIPAA
  • GDPR

Product

  • Overview
  • PDF tools
  • Diagram tools
  • People & HR
  • Integrations
  • Marketplace
  • Pricing

Resources

  • Guides
  • Glossary
  • Compare
  • Docs
  • API reference
  • Support
  • Changelog
  • Status

Company

  • About
  • Careers
  • Press
  • Contact

Legal & trust

  • Trust center
  • Security
  • Privacy
  • Terms
  • DPA
  • GDPR
  • SLA
  • Refunds
  • Google API data
Atlas, a product by wrxstack.com·© 2026 wrxstack·All rights reserved
PrivacyTermsSecurityStatus