The economics of the quick favor: what one-line Slack requests really cost

It usually starts in a shared Slack channel on a friendly afternoon. "Quick one: could the export include the region column too?" A developer who wants the client to be happy replies "sure, will sneak it in" and ships it the same day. Nobody opens a ticket. Nobody checks the SOW. The client is delighted, and on its own the favor is a good decision.

The problem is that it is never on its own. In TWINJAM's onboarding audit, 82% of out-of-scope requests first appeared in Slack or Teams rather than in a ticket or an email. Chat is where requests feel smallest, because the medium itself is casual. A one-line message implies a one-line change.

This post walks through the real cost of that one-line change, using a worked example that you can rebuild with your own rates. The goal is not to stop doing favors. It is to know what they cost, so that the ones you give away are chosen rather than accumulated.

Take a request a developer estimates at one hour of coding. Now follow it through your delivery process the way it really runs.

The build is less than a third of the effort. Everything around it, clarifying, switching, reviewing, testing, and the inevitable follow-up, is where the cost hides. Teams that estimate favors by build time alone are underestimating by a factor of three or more.

At a blended internal cost of $55 per hour, that is $187 of delivery cost. At a billing rate of $140, it is $476 of work the client would have paid for if it had been in the SOW. Neither number feels large. That is precisely why the pattern survives.

Now scale it. A typical six-month fixed-fee build has one or two client stakeholders active in Slack every working day. If they make two small asks a week, which is modest, the project absorbs around 50 of them before launch.

• 50 favors at 3.4 hours each is 170 hours of unplanned delivery.
• At $55 internal cost, that is $9,350 of cost that was never priced into the fee.
• At $140 billing, it is $23,800 of work delivered and never invoiced.
• On a $120,000 project planned at 50% gross margin, the margin falls to roughly 42% from favors alone, before any formal change is discussed.

This is how agencies end up with projects that were "on budget" by every milestone report and still lose money. The large change requests get noticed and priced. The small ones go into the fee, one at a time, and the margin quietly moves.

A single 40-hour request triggers a process. Someone estimates it, a PM raises it, the client approves or declines, and the plan adjusts. Fifty two-hour requests bypass all of that. They also do damage that a big change does not:

1. They fragment focus. Sprint work slows down because developers are constantly interrupted, which makes the planned scope late and creates pressure to cut corners elsewhere.
2. They set a precedent. Each favor teaches the client that chat is a valid route for new work, so the next request arrives the same way.
3. They erase the evidence. Without a ticket, there is no record when the project runs over and the founder asks why.
4. They make the eventual conversation harder. Raising a change order in month five feels like an ambush if the previous forty asks were free.

Clients rarely object to paying for work. What they object to is surprise. The fix is to make small requests visible early and bill them in a predictable rhythm, rather than to refuse them in the moment.

Log every ask, even the ones you give away

A favor that is logged is a decision. A favor that is not logged is a leak. Keep a running list per project with the request, the date, the estimate and whether you chose to absorb it. Showing a client "we included these six items at no charge this month" builds goodwill that an invisible favor never does.

Agree a small-change allowance up front

Some agencies write a monthly allowance into the SOW, for example up to eight hours of small changes, after which items are batched into a change order. The client gets flexibility, the team gets a ceiling, and nobody has to negotiate each one-line request.

Batch the rest into one monthly change order

Instead of raising fourteen tiny change orders, raise one at month end that lists them with dates, links to the original messages and hours. A single itemized document reads as organized and professional. Fourteen separate asks feel like a running meter on the relationship.

Reply to the request, not the person

The language matters. "Happy to add that. It sits outside the current SOW, so I will add it to this month's change list, about three hours" is warm, factual and takes ten seconds to write. It does not say no and it does not argue. It just makes the cost visible.

The reason favors slip through is not that PMs do not care. It is that nobody can read every Slack thread across fifteen client channels and compare each message against a forty-page SOW. That comparison is the part software is good at. TWINJAM watches the channels you select, matches requests to the clause they touch and drops a private alert into the PM's feed with an hour estimate.

What tooling should not do is talk to the client. The decision to absorb, batch or raise a change is a relationship call that belongs to the PM, and TWINJAM never sends anything to a client without PM approval. The goal is a team that knows exactly what it is giving away, and gives it away on purpose.