Responding to an RFP before the deadline

How the Consulting pack runs an RFP response from the client's dates and a partner's bid or no-bid decision to pricing, documents and submission.

By Achekam · 11 October 2026 · 4 min read · For Consulting businesses in South Africa, Nigeria, Kenya

Launching soon. The Industry CRM add-on described in this article is launching soon. This article describes it as it will work at launch.

A request for proposals lands with a closing date a few weeks away. For most of that time it sits in a partner's inbox while everyone is busy with paying work. In the final days the team writes through the night, discovers on the last afternoon that a returnable form needs the signature of someone who is on leave, and submits with minutes to spare, or not at all.

Achekam's Consulting pack runs the response as a workflow, so the work is spread across the time available and the deadline is visible from the first day rather than the last.

Recording the client's dates

The workflow begins by recording the client's dates. An RFP usually has several: a deadline for clarification questions, perhaps a briefing session, the closing date and time, and sometimes a period for which the offer must remain valid. Put all of them on the proposal as soon as the RFP arrives. If your team is new to formal bids, Investopedia's explainer on the request for proposal covers what an RFP asks bidders to supply, its pros and cons, and how it differs from a request for quote or a request for information.

Use the clarification deadline. Questions asked early often reveal what the client really cares about, and the answers, usually shared with every bidder, can change how you price and present the work.

The pack reads no tender portal. Dates and requirements reach the pack because someone enters them. Make it one named person's job to read each RFP on the day it arrives, record every date, and list every requirement, including the dull ones about format, page limits and how the response must be delivered.

The bid review and a partner's bid or no-bid decision

Next comes a bid review, and then a partner decides: bid or no bid. Doing this early is the whole point. A no-bid decision in the first days frees the team for other work; the same decision a day before the deadline wastes the effort already spent.

A bid review should answer a few blunt questions:

• Do we have the skills and the people to deliver this if we win?
• Can we meet every mandatory requirement, including the returnable documents?
• Do we know this client, or are we one name on a long list?
• Can we price it at a level that is worth winning?

If the partner decides not to bid, the proposal ends as Not bid, and the decision is on record for the next time a similar request arrives.

Pricing the work

Pricing is its own step in the workflow, separate from writing the response. Give it to whoever owns the firm's rates and margins, and start it early. Pricing questions often lead back to the scope of what you are proposing, and discovering that on the last day forces either a rushed rewrite or a price you will regret.

Write down the assumptions behind the price as you go: days per deliverable, who does the work, travel, and anything you have excluded. If the bid is won, those assumptions become the starting point for the statement of work.

Gathering returnable documents

Most RFPs ask for documents that have nothing to do with the substance of the proposal: registration certificates, tax certificates, signed declarations, forms, CVs, references. The workflow has a step for gathering them.

This is where submissions fail on technicalities. Start this step on the first day:

• list every returnable document the RFP names;
• check expiry dates on certificates you already hold, and apply for renewals now if needed;
• identify every document that needs a particular person's signature, and when that person is available;
• keep the gathered set in one folder, with a note of which requirement each document answers.

Tasks, subtasks and submission

A workflow creates its tasks stage by stage, and tasks can have subtasks up to three levels deep. An RFP response suits that shape well: a task for each section of the response with a subtask for each contributor, and a separate task for returnable documents with a subtask per document.

The workflow ends with submission before the deadline. Set your own internal deadline well ahead of the client's, so the final hours are spent checking rather than writing. A response submitted early and checked properly beats one that is slightly better written and late.

Meanwhile the proposal moves through its stages: Bid review, Writing the response, Submitted, then Shortlisted if the client keeps you in, and finally Won, Lost or Not bid.

After submission, keep a copy of exactly what was sent, together with the client's acknowledgement of receipt, on the proposal's file. If the client later asks a clarification question, or the bid is challenged, you will want the submitted version rather than the last draft on someone's laptop. Then move the proposal to Submitted and put a date on it for following up, because clients rarely announce their decisions on time.

A response timetable

If the bid is won, the work moves on to a statement of work and, later, a routine of monthly check-ins. For what the outcomes of many responses can teach the firm, see tracking proposals to won, lost or not bid.

When the next RFP arrives, hold the bid review within the first few days and record the partner's decision, whichever way it goes. That one change does more for the deadline than any amount of late-night writing.

General guidance only, not advice on your own circumstances. Tax and payroll rules change: check the current position with the authority or your adviser.