What is a send-back?
A send-back is what happens when an approver rejects a Digital FTE's proposal and returns it with a reason. The proposal does not happen; the FTE revises against the reason; and the send-back, its reason, and the revision are logged in the audit trail. It is the third of the approver's three choices at the approval gate, after approve and edit.
The reason is the point. A rejection without a reason teaches nothing; a rejection with one is an instruction the FTE can act on now and the manager can generalise later.
How do send-backs work on ftes.ai?
On ftes.ai the send-back button in Approvals requires a reason, in a sentence. The Digital FTE revises the proposal against it and resubmits, and the pair appears in the approval record for that category. At the weekly review in the first month, and monthly thereafter, the manager reads the send-back reasons grouped by category.
A reason that repeats is a rule the remit is missing or a Brand Brain item that is wrong: a register the brand never uses, an account that should be protected, a product fact that is out of date. The manager fixes it once, at the source, and the category's send-back rate falls.
Why is the send-back rate the honest cost measure?
It is the honest cost measure because a send-back is the human time that a proposal actually cost: the reading, the reason, and the review of the revision. A proposal approved unchanged cost the minutes of reading it; a send-back cost three times that. The send-back rate per category, read alongside usage per role, is therefore the editing time the FTE consumes, which belongs in the total cost of ownership.
It is also the honest quality measure, because it distinguishes work that was done from work that was right. An approval rate is the flattering number; the send-back reasons are the useful one.
How do send-backs drive the autonomy ladder?
The autonomy ladder is climbed on the absence of send-backs: a class of action with a long run of approvals and no send-backs is a candidate for promotion. And it is descended on their presence: a send-back in a promoted class, meaning an auto-approved action that a person on seeing it would have rejected, steps the class back to gated the same day while the cause is found.
So the send-back is the ladder's evidence in both directions. A manager who gives reasons consistently builds a record that promotion decisions can be made from; one who rejects silently builds nothing.
- Long clean run, no send-backs: candidate for promotion
- Send-back in a promoted class: step back, find the cause
- Repeated reason in a category: fix the remit or memory
- Scattered reasons: usually fine, note and move on
What is a send-back often confused with?
It is confused with an edit, which is the approver changing the proposal and approving it; an edit teaches less because no reason is recorded, and a manager who edits every time should ask whether a send-back with a reason would fix the pattern. It is confused with a failure of the FTE; most send-backs are a remit gap, and the reason says so.
It is sometimes treated as a mark against the role. Early send-backs are expected and useful; a role with none in its first weeks is a role whose manager is not reading closely.
Where do you see send-backs in the workspace?
Each proposal's history in Approvals shows its send-backs and reasons. The Performance tab shows the send-back rate per category alongside the approval rate, and the monthly review reads the reasons grouped. The audit trail keeps every one with the approver's name and the date.
Related terms: approval gate, approval rate, autonomy ladder, remit, monthly review.
A last practical point: write the reason for the FTE, not for the file. A reason such as too formal for this segment, or this account is a key customer and should never receive automated outreach, is one the FTE can act on in its revision and one the manager can turn into a rule at the review. A reason such as no is neither.