Agency and Dev Team Coordination: The Request–Delivery Process

Agency and Dev Team Coordination: The Request–Delivery Process

The product team wants a feature. They tell the agency or external dev team. An email, a Slack message, maybe a Notion page. The dev team thinks they understood. They develop it. They deliver it.

"This isn't what we asked for."

Revisions start. The second delivery still has something missing. By the third, "actually at the start we said it should be like this" comes up. Project delay becomes inevitable.

This coordination problem between agency and product team is so common it's started to be treated as "natural." It isn't. It's a structural problem — and it has a structural solution.

Why Does Work Get Lost in External Team Coordination?

Working with an agency or external dev team is different from standard internal coordination. Two sides work in separate systems, with separate priorities and separate contexts.

Requests are communicated unclearly. "Update that page" isn't a request. Which elements will change, what constraints exist, what's the design reference, what are the acceptance criteria — without these written down, the request gets interpreted differently by both sides.

There's no approval step. The request was communicated, the dev team started development. But was the request understood correctly? Not checked. Two weeks later, "that's not what we meant" comes out.

Delivery criteria aren't defined. What does "ready" mean? For the dev team it means working in staging. For the product team it means fully correct across all browsers, all scenarios, matching the design precisely. When this gap isn't written down, revision is inevitable.

Change requests enter uncontrolled. New requests come from the product team during development. These get added to the original request, scope expands, the delivery date slips. Nobody tracks the scope change.

The Request–Delivery Flow in Alios

Agency dev team coordination in Alios is built around a five-step flow. Every step has an owner, an output, and a transition criterion.

Step 1 — Request Record

Every request from the product team — big or small — gets opened as a node. Verbal or Slack-based requests don't go into development without entering the system.

📌 REQUEST — [Short title]
Status: Request Received
Opened by: [Name from product team]
Date: [Request date]
Owner (initial): [Request coordinator]

📋 REQUEST DETAIL

What is requested:
[One paragraph — what should change, what should be
added, what should be removed. If possible, from the
user's perspective:]
"The user should be able to / see / not be able to [X]"

Why it is requested:
[Business rationale — what problem is being solved,
what metric will improve]

References:
[Figma link, example URL, related screenshot]

Constraints:
[Technical constraint, brand constraint, date
constraint if any]

Expected delivery date:
[Product team's expectation]

Step 1 output: Request is on record, has context, references attached.

Step 2 — Approval and Scope Clarification

After the dev team receives the request, they don't start development. They first write their understanding and get approval. This is the most commonly skipped but most value-adding step.

📌 APPROVAL NOTE [added to Step 1 node]

Status: Awaiting Approval
Written by: [Name from dev team]
Date: [Approval note date]

Dev team's understanding:
[Dev team summarizes the request in their own words.
Format: "We understand this as: ..."]

Planned approach:
[What will be done technically — high level]

In scope:
- [Thing to be done 1]
- [Thing to be done 2]

Out of scope:
- [Thing not to be done — not part of this request]

Effort estimate: [Days / Sprint]
Delivery date: [Dev team's commitment]

Questions:
- [Unclear point 1]
- [Unclear point 2]

PRODUCT TEAM APPROVAL:
[ ] Approved — development can start
[ ] Revision needed — [What should change]
Approved by: [Name] — Date: [Date]

This approval note does two things: misunderstandings get caught before development starts, and scope change requests become manageable through the "out of scope" list.

Step 2 output: Both sides understand the same thing that will be built. Written approval exists.

Step 3 — Development

Once approval is received, the development node is opened.

📌 DEVELOPMENT — [Request name]
Status: In Development
Owner: [Name from dev team]
Deadline: [Agreed delivery date]
Linked request: [Step 1 node name]

Daily update area:
[Dev team adds every update here —
without requiring a meeting or message]

[Date]: [What was done, where]
[Date]: [Blocker if any, what the solution is]
[Date]: [Completed parts]

Staging link: [When ready]
Test account: [Info needed for QA]

The daily update area is critical. The product team can see the current status by looking at the node without asking "where does this stand?"

Step 3 output: Development complete, visible in staging.

Step 4 — Delivery and Acceptance Testing

Before the dev team says "ready," they check the delivery criteria.

📌 DELIVERY NOTE [added to development node]

Status: Awaiting Acceptance Testing
Date: [Delivery date]

What was delivered:
- [Thing done 1 — where to see it in staging]
- [Thing done 2 — where to see it in staging]

Left out of scope:
- [Items defined as out of scope in Step 2]

Test environment:
Staging URL: [Link]
Test account: [Username / password]
Test scenarios: [Steps for QA]

Dev team's own checklist:
- [ ] All agreed acceptance criteria met
- [ ] Edge cases tested
- [ ] Mobile view checked
- [ ] No errors in console
- [ ] Ready to demonstrate to product team in staging

Step 4 output: Dev team completed its own QA, ready to deliver to product team.

Step 5 — Product Team Approval and Close

📌 ACCEPTANCE APPROVAL [added before node closes]

Status: Done / Revision Needed
Reviewer: [Name from product team]
Date: [Review date]

[ ] APPROVED — can go to production
    Approved by: [Name] — [Date]
    Go-live date: [Date]

[ ] REVISION NEEDED
    What is missing / incorrect:
    • [Item 1 — specific, testable]
    • [Item 2 — specific, testable]

    Is this revision in scope?
    [ ] Yes — within the original request scope
    [ ] No — will be opened as a new request

The last line matters. The distinction between whether a revision is within the original scope or a new request prevents scope creep.

Step 5 output: Approval received and went live, or revision opened as a new request.

Example Scenario: Landing Page Update

Situation: The product team sends the agency a request to update the landing page hero section.

📌 REQUEST — Hero Section Update
Status: Request Received

What is requested:
Hero headline and subheadline are being updated.
Text will change according to the new value
proposition. CTA button color will be orange
in line with the brand update.

Why it is requested:
A/B test results showed the current headline
is lowering conversion rate. New copy will be tested.

References: [Figma link] [A/B test report]
Constraints: Font family won't change, layout preserved
Expected delivery: 5 business days

The agency writes the approval note:

Dev team's understanding:
H1, H2 text and CTA button color in the hero
section will change. Layout, font, images stay the same.

In scope: Text changes, button color change
Out of scope: New visual, animation changes,
mobile layout redesign

Effort: 1 day
Delivery: [Date]

Question: Will the CTA hover color also be orange,
or will the current hover style be kept?

Product team approves, hover question gets answered, development starts. On delivery, "that's not what we meant" doesn't appear. No revision.

Final Thought

Lost work and revision cycles in agency and dev team coordination aren't inevitable. Most problems come from unclear requests, skipped approvals, and undefined delivery criteria.

The five-step flow in Alios systematically solves these three problems. Requests are written down, approval is required, scope is defined, delivery criteria are clear. Both sides look at the same node, work with the same expectation.

"This isn't what we asked for" gets heard a lot less. Because what was asked for was written down from the start — and both sides read it.