Referral programme coordination: estimating effort and available capacity

Editorial illustration of Referral programme · Effort and capacity

This guide focuses on estimating work and availability without confusing effort with a delivery date. The worked example follows three units: “referral request”, “contact follow-up” and “status closure”.

Reference input: programme rules and touchpoints. Expected output: a referral operations register. Before assigning work, confirm the current input version and who will review the result.

Estimate observable work units

To estimate the referral programme coordination, split the outcome into units another person can recognize. Here, use referral request, contact follow-up and status closure. Describe what each includes and where it ends. A task called “manage the project” cannot meaningfully be compared with execution. Separate preparation, production, review and correction when they consume different capacity. An exhaustive task tree is unnecessary: expose the parts that materially change effort and the dependencies that determine when they can be performed. This gives the team a basis for discussing uncertainty without pretending that every minute is predictable.

Use ranges and state their assumptions

An initial estimate should explain why a unit might take longer. Set a lower and upper bound tied to observable conditions: complete inputs, one review round and specialist availability. If the required inputs are incomplete, acknowledge that uncertainty in the range. Do not turn the optimistic endpoint into a promised delivery date without discussing its assumptions. When records of comparable work exist, compare them with the range and explain what differs in this assignment. Comparisons improve planning when they retain each unit's context instead of treating all similarly named tasks as equivalent.

Worked example

The fictional programme receives two referrals for one contact through different touchpoints. The register prevents duplicate follow-up and preserves authorized origin. Each state describes a verifiable action without treating a received referral as a completed sale.

The example involves Sofia, Valeria and Camila. Names, situations and numbers are illustrative and do not represent customer results. The three units let you test the proposed approach before extending it to other work.

UnitIllustrative productionReview / correctionAssumption
referral request2 hShared review: 1.5 hComplete inputs
contact follow-up2 hTotal expected correction: 1 hOne review round
status closure2 hWhole set: 8.5 hCapacity: 3 effective h/day
Worked-example diagram: Referral programme · Effort and capacity
Diagram of the illustrative example. The table and text explain the complete records and their conditions.

Separate capacity from elapsed delivery time

In this illustrative example, three units require 2 hours each, joint review takes 1.5 hours and expected correction takes 1 hour. Baseline effort is 8.5 hours. If the executor has 3 effective hours per day for this assignment, 8.5 hours does not imply same-day delivery. Review may also follow a waiting period. Distinguish working hours, available capacity and elapsed time until acceptance. These numbers are planning assumptions for the example, rather than observed productivity or team guarantees. The delivery conversation needs to address all three measures explicitly.

Re-estimate after a material condition changes

Update the calculation when volume, source version, acceptance criteria or reviewer availability changes. Retain the previous range and explain the difference. To avoid leaving a duplicate referral with two different owners, reserve time to check the identifier and latest authorized follow-up. An apparently small correction may affect several units; identify those units before adding a generic contingency allowance. At closure, record actual effort and reasons for deviation using the same breakdown. That evidence can inform the next assignment without turning a single execution into a universal benchmark. The purpose is a better supported decision, rather than a more precise looking number.

What to check before closure

The risk to control in this case is leaving a duplicate referral with two different owners. A completed label needs a supporting observation. Keep the following beside the decision so the receiver can establish what was checked:

  • Input and version used: programme rules and touchpoints.
  • Case check: check the identifier and latest authorized follow-up.
  • Outcome under review: a referral operations register.

Your privacy on this blog

Choose our own statistics, Google Analytics, Cloudflare, and Google Signals with personalized advertising. The last option allows audiences for GGyess ads and combines your activity with Google data; it also requires permission for Google Analytics. Accept all allows the available options, including advertising when available; it does not subscribe you to the newsletter. Necessary only rejects every option. Permissions last up to 180 days; we remember advertising refusals for 12 months.

Necessary preferences

Remember your language, display theme and privacy choice. These preferences are not used to measure your reading.

Privacy notice · Privacy requests: myprivacy@gloadi.com