Playbook: scope creep protocols

Проблема: клиент во время работы над order начинает просить больше чем было в original scope. Классические примеры:

“Ещё можешь добавить маленькую фичу?”
“Это же почти то же самое, зачем отдельно считать?”
“Ну вот смотри, тут ещё нужно сделать X, это же у тебя занимает 10 минут”
“А ещё у меня другой проект, там похожая задача, можешь сразу и её?”

Риск: если соглашаться — work grows без compensation, delivery delayed, team burns out, project становится loss-maker. При repeated scope creep — cancel culture, review decline.

Цель плейбука: иметь precisions protocols на каждый сценарий, чтобы Front мог отвечать немедленно без consultation с tech team.

Основной принцип

Scope creep всегда обрабатывается через custom offer, никогда через “ok, я сделаю”.

Не потому что мы жадные. Потому что:

Fair exchange — работа должна быть compensated
Timeline protection — новое scope = новый timeline, buyer должен это принять явно
Fiverr audit trail — если позже спор, Fiverr видит чёткие boundaries каждого order
Предсказуемость для tech team — планировать сложно если scope плавает
Precedent management — one “just this once” создаёт expectation “always”

Шаг 1: detect scope creep early

Red flags в первом inquiry message

Warning signs что buyer будет pushing scope:

“Flexible on scope”
“Can you also…”
“Just a quick addition”
“While you’re at it”
“Oh and one more thing”
“Is it easy to add…”
“I know it’s not in the gig but…”
“You said you’re good with X, so maybe Y too?”
“My friend needs something similar”

Не отказываться от buyer’а, но быть готовым применить protocol immediately.

Clarify scope upfront

В первой custom offer сформулировать максимально конкретный scope с явным “What’s NOT included” списком.

См. Custom offers playbook — секция “What’s NOT included”.

Пример “Not included” для Claude integration gig:

Not included (priced separately if needed):
- Vector DB setup (if existing infra not suitable)
- UI/UX redesign beyond component styling
- Multi-language support
- Mobile app version
- Building Next.js app from scratch
- Backend API changes outside the chat endpoint
- Additional tools beyond the 3 listed
- Third-party integrations (Slack, Email, etc)

Когда buyer позже просит что-то из этого списка — можно просто указать “we discussed this was out of scope”, и предложить custom add-on offer.

Шаг 2: categorize request

Когда клиент просит что-то дополнительное, classify:

Category A — trivial (< 30 минут работы)

Примеры:

Изменить текст кнопки
Переименовать переменную
Перекинуть стиль с чёрного на белый
Add missing error message

Protocol: делать без custom offer.

Rationale: goodwill > $20 revenue. Просто сделать. Это normal revisions, не scope creep. Большинство гигов разрешают 2-3 revisions без вопросов.

Правило: максимум 2-3 trivial requests. Если buyer начинает список из 15 таких — это уже scope creep, переходить к Category B/C protocol.

Category B — small additional feature (1-5 часов работы)

Примеры:

Add one more tool to Claude agent
Add one more table to RLS audit
Add English translation to landing
Add admin “delete user” button
Integrate one more API endpoint

Protocol: custom offer с flat add-on цена.

"Happy to add [feature]. This is beyond the original scope so
I'll send a custom offer: $[X], +[Y] days to timeline. Fair?"

Цена: $300-800 depending on complexity. Обычно $500 default для “small feature”.

Category C — substantial new work (5+ часов работы)

Примеры:

Add entire feature area (e.g., billing)
Add multi-tenant architecture
Add mobile support
Migrate to different database
Full redesign

Protocol: отдельный custom offer как new project, with separate timeline.

"That's a substantial addition — closer to a new project than a
revision. Let's close this current order (deliver what we have),
and I'll send a fresh custom offer for [new feature] as a separate
project. That way both get proper attention. Current order: on track
for delivery [date]. New project: I'll send offer in [chat] for your
review."

Почему separate: смешивать large new scope в existing order = mess. Fiverr timelines, revisions, disputes, reviews — всё привязано к single order. Разделение даёт clean state для обоих.

Category D — out of capability or legal issue

Примеры:

“Can you also do SOC2 certification?”
“Can you host production server for us?”
“Can you be on our payroll?”
“Can you sign NDA with custom terms?”
“Can you delete user data from our DB?” (regulatory)

Protocol: polite decline + offer relevant gig если есть.

"Unfortunately that's outside what we do via Fiverr. [Reason:
we don't offer hosting / legal / payroll services]. If you need
help with [adjacent gig we have], happy to discuss that separately."

Шаг 3: handle specific scenarios

Scenario 1: “Можешь добавить X, это же 10 минут”

Reality: часто buyer underestimates by 5-10x. “10 минут feature” = 2-3 часа работы + testing + revisions.

Response:

"Good idea — but even small features take about 1-3 hours when
you include testing, integration, and revisions. I'll send a
custom offer: $[X] for this addition. If you prefer to skip it,
ok, we stick with original scope."

Key: calmly explain что 10 min рarely is 10 min. Don’t argue, just quote.

Scenario 2: “Друг/партнёр has similar task, can you do that too?”

Reality: referral opportunity wrapped as scope creep.

Response:

"Sure, happy to help them — but it'll need to be a separate Fiverr
order under their account. Fiverr tracks orders per buyer so we
can't combine. Share my profile with them: [URL]. They can order
directly or I can send them a custom offer if they reach out."

Bonus: возможно получить referral — новый client. Не upsell текущего.

Scenario 3: “Just make it work like Figma / Notion / Linear”

Reality: buyer подставляет benchmark который требует years of engineering.

Response:

"Love the reference — but Figma/Notion/Linear each have 100+
engineers behind them. Our scope is to deliver a working solution
for your specific use case with the features in the custom offer.
If you want something closer to [reference], I can send a larger
custom offer — typically $15-30K for that level of polish, 2-3
months timeline. Let me know."

Key: re-anchor expectations. Often buyer просто impressed, не really asking для full Notion clone. Setting market price for real thing scares them back to reality.

Scenario 4: “You said you’d deliver X, this isn’t X”

Reality: misunderstanding или buyer перечитал original scope differently than intended.

Response:

"Let me look at the original custom offer text. [Quote exact
bullet]. If you're reading it differently, let's align on what
was meant. I'd rather clarify now than argue at delivery."

Key: go back to the written scope. If buyer’s interpretation is reasonable, delivering что-то что approximates intent — ok. If clearly different — follow Category B/C protocol.

Scenario 5: “Free trial / let me try it first”

Reality: buyer wants work done before paying.

Response:

"We don't do free trials, but here's what I can offer:
- Basic tier ($500) — smallest scope, 3-day delivery, 1 revision.
  Low commitment. If you're happy, you can upgrade / continue
  with us for bigger work.
- Live demo call (15 min) — walkthrough similar work we've
  shipped, explain approach. Free.
- Sample code — from our public GitHub. Free.

Which sounds good?"

Never: free work. Sets precedent, attracts wrong buyers.

Scenario 6: “Разделим cost on your side?”

Reality: buyer wants Upready.dev to work at loss as “investment”.

Response:

"We don't do equity / cost sharing on Fiverr orders — it's not how
the platform works. If you're interested in a strategic partnership,
let's discuss separately after this project delivers, not as part
of payment structure."

Scenario 7: Ticking timer on delivery day

Situation: delivery день -1, client suddenly says “oh I also need X”.

Response:

"Tomorrow is delivery day, which means this is the wrong time to
add scope — we'd miss the deadline and that hurts both of us
(review, ranking, your expectations). Let's deliver the original
scope on time. After delivery, I'll immediately send a custom
offer for [new ask], with its own 3-5 day timeline. Fair?"

Key: protect delivery deadline. Miss deadline = auto-cancel или decreased ranking.

Шаг 4: если scope creep becomes pattern

Если один buyer shows scope creep pattern multiple times in one order:

3-strike rule

Strike 1 (small request): do if trivial, mention “this is included as goodwill, not a precedent”.

Strike 2 (second request): send Category B custom offer, say “this is beyond scope so proper offer”.

Strike 3 (third request in same order): pause. Message:

"I want to deliver high quality work on what we agreed. Scope has
grown several times since the original offer — at some point we
need to either close current scope cleanly OR upgrade to a bigger
scope-of-work. I prefer option 1 (close clean, new project for
additional work). Can we align on that?"

Buyer responds positively: deliver original, send new project offer.

Buyer argues: escalate — “If we can’t agree on scope boundaries, I recommend we cancel this order via mutual agreement and restart with a clearer contract. Fiverr cancellation removes it from ranking but is better than a frustrating delivery for both of us.”

Never: just do unlimited work to “keep the client happy”. That’s the road to burnout and bad reviews.

Шаг 5: document для tech team

Every scope creep event — log в internal Notion:

Client: [name]
Date: [date]
Original scope: [brief]
Creep request: [what was asked]
Category: [A / B / C / D]
Response: [what Front said]
Outcome: [accepted custom offer / declined / delivered as goodwill]
Lessons: [anything to change in next similar situation]

После 10-20 such logs — pattern анализ. Use для:

Improve gig descriptions (add to “Not included”)
Improve initial custom offers (anticipate common additions)
Improve team briefing (common traps)

Fiverr-specific considerations

Fiverr’s position on scope creep

Fiverr supports seller maintaining scope via custom offers. Platform actively encourages:

Custom offers for add-ons
Cancellation by mutual agreement for serious disputes
Buyer review moderation if scope abuse obvious

НО: Fiverr’s default UI pushes buyer to “request revision” — which doesn’t discriminate between legitimate revisions and scope creep.

How to use revisions без scope creep

Legitimate revision (включено в tier):

Изменить цвет
Fix a bug
Correct misunderstanding in existing scope
Clarify unclear deliverable

Scope creep через revision UI:

Add new feature via “revision request”
Restyle entire design via “revision request”
Add new tool / endpoint / table via “revision request”

Protocol: when revision request is actually scope creep, reply in chat first:

"Got your revision request. I see you're asking for [X] — that's
beyond the original scope. Can I send a custom offer for this as
an add-on? If you prefer to use a revision round for a different
change, let me know what."

Then submit the original delivery via Fiverr interface (not the new scope), forcing buyer to either accept delivery + custom offer, or clarify revisions.

KPI scope creep management

Metric	Healthy	Warning
% orders with scope creep requests	< 50%	> 80%
Avg scope creep cost (if accepted)	20-50% of original	> 100%
Orders where Front said “no” to creep	30-60%	< 10%
Custom offers sent for add-ons	1-2 per order	5+ per order
Reviews complaining “didn’t do what I wanted”	< 2%	> 10%

Связанные страницы

Playbook: custom offers — mechanism для handling add-ons
Playbook: first order — includes creep handling for new accounts
Термин: Custom Offers
Risks and fallback