--- title: "Platform team intake: handling requests · DeliverySheet" description: "An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list." canonical_url: "https://www.deliverysheet.com/blog/platform-team-intake" last_updated: 2026-10-10 meta: author: "Tan Gravam" "og:description": "An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list." "og:image": "https://www.deliverysheet.com/_og/s/o_900ca048703b0d77.png" "og:image:alt": "How a platform team should take requests from other teams — DeliverySheet essay card" "og:image:height": "600" "og:image:type": image/png "og:image:width": "1200" "og:title": "How a platform team should take requests from other teams — DeliverySheet" "twitter:description": "An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list." "twitter:image": "https://www.deliverysheet.com/_og/s/o_900ca048703b0d77.png" "twitter:image:alt": "How a platform team should take requests from other teams — DeliverySheet essay card" "twitter:title": "How a platform team should take requests from other teams — DeliverySheet" --- > Index of every page on this site: [llms.txt](https://www.deliverysheet.com/llms.txt) [← All writing](https://www.deliverysheet.com/blog) # **How a platform team should take requests from other teams** 10 October 2026 · 5 min read · by [Tan Gravam](https://www.deliverysheet.com/about) ## **How should a platform team handle requests from other teams?** **The short answer ** A platform team should handle requests from other teams through two doors. Support, meaning something is broken or someone needs help, goes to a weekly rotation and one channel and is answered the same day. Requests for the platform to change go through an intake that asks three things: what the team is trying to do, what it costs them while it stays as it is, and whether a date is attached. Once a week every request gets one of four answers in writing: planned, a short look first, not now with a review date, or no with the reason. Publish the committed, parked and declined lists so requesting teams can see each other. When two teams both need something first, someone above both sets the order. A platform team has an unusual problem with requests: its customers sit twenty metres away, know each engineer by name, and are blocked until they get an answer. So requests do not arrive in a queue. They arrive in a direct message, in a stand-up, in a pull request comment, and each one is small, reasonable and urgent to the person asking. The same is true of any team other teams depend on: data, security, developer experience, infrastructure. What follows is an intake process sized for that situation, which is different from intake for a product team. ## What makes a shared team's intake different - **The requesters are engineers.** They arrive with a solution ("add a flag to the deploy tool"), not a need. The need behind it is often cheaper to meet another way. - **Every request is someone else's blocker.** So every request is urgent, and urgency stops carrying information. - **The requesting teams cannot see each other.** Each knows what it asked for. Nobody but the platform team knows the total, which is why the total is always more than fits. - **Half the work is not project work.** Questions, access, a broken pipeline: support that has to be answered today and should never wait for a planning cycle. ## Two doors, not one The most useful single change is to separate what is support from what is a request for the platform to change. **Support** is "this is broken" or "how do I". It goes to a rotation: one named engineer this week, one channel, answered the same day. It is sized as a standing line in the team's capacity, the same way [keep-the-lights-on work](https://www.deliverysheet.com/glossary/ktlo) is, and it is not planned item by item. **Requests for change** are "the platform should do something it does not do". These go through the other door, get a decision, and compete for the capacity that is left. Without the split, the rotation engineer builds features in the gaps and the roadmap is interrupted by questions. With it, a direct message has an obvious answer: "that's support, ask in the channel" or "that's a change, put it through the door". ## What the door asks Three things, and none of them is the solution: 1. **What are you trying to do** that you cannot do now? 2. **What does it cost you** while it stays this way: time per week, a blocked launch, a risk? 3. **Is there a date** it is tied to, and what happens on that date? That is [the same three-question intake form](https://www.deliverysheet.com/blog/intake-form-template) any team should use, and it matters more here. Asking for the need first is what lets the platform team answer "you can already do that with X" or "three teams have asked for the same thing differently". A request that names only a solution is [a topic, not yet a request](https://www.deliverysheet.com/blog/a-topic-is-not-a-request), and it goes back with one question the same day. ## Decide in the open, on a rhythm Once a week, the platform team goes through what came in and gives each request one of four answers: we will plan it, we need a short look first, not now (with a date we look again), or no (with the reason). The answer goes back to the requester in writing that day. Publish the list. One page that every requesting team can read: what the platform team has committed to this quarter, what is parked and until when, what was declined and why. This does more than any prioritisation method, because it lets the requesting teams see each other. A team that reads that its request lost to a security deadline argues much less than one that was told "we're busy". ## When two teams both need it first The platform team should not be the one to choose between two product lines. It can say what each request costs and what fits; it cannot say which product matters more. When the capacity runs out between two requests from different teams, the order is [set once, by someone above both teams](https://www.deliverysheet.com/blog/capacity-planning-across-product-lines), and the platform team works down it. The alternative is that the choice is made anyway, by whichever requester is more persistent or better connected. That is [the side channel](https://www.deliverysheet.com/blog/the-side-channel), and a shared team is where it does the most damage, because each favour is paid for by a team that never finds out. ## What not to build - **A long request form.** Engineers will fill in a twelve-field form once, and then go back to direct messages. - **A priority field for the requester.** Everything will be P1. Ask for the cost and the date; priority is the team's decision. - **An SLA on changes.** Promise a decision within a week, not delivery. A delivery promise made before sizing is the thing intake exists to prevent. - **A ticket for every question.** Support that takes five minutes should take five minutes. ## If you use DeliverySheet The product covers the second door, requests for change, and does not try to be a support desk. A request is captured as pasted text and enters the process only when it states the need plus who it affects or why now. Each one then gets one of four recorded decisions: plan it, run a time-boxed discovery, park it or decline it. A park needs a reason and either a review date or an explicit choice to park indefinitely; a decline needs a reason. Capacity is agreed per team when the work is planned. The published list is the workspace itself: requesters who are members can read the parked and declined demands with their reasons. Every member signs in with Google. I'm Tan Gravam. I build **DeliverySheet** — it takes a vague work request to a clear delivery decision, so the shape, owner, capacity, dependencies and open questions are on the table before anyone commits people or a date. $189/month per workspace, unlimited members. 7-day free trial — card required, cancel before it ends and you're not charged. I answer the support email myself. [**Start 7-day trial **](https://www.deliverysheet.com/login?next=/app) [**See pricing **](https://www.deliverysheet.com/pricing) Not ready for that? Play [eight rounds of Request or topic?](https://www.deliverysheet.com/spot-the-request) It takes two minutes and needs no sign-up. ## **More on turning a request into a decision** [Read the overview: Turning a request into something you can decide on →](https://www.deliverysheet.com/topics/intake) - [Five honest alternatives to the intake spreadsheet](https://www.deliverysheet.com/blog/spreadsheet-intake-alternatives) Keep the sheet, move to Airtable or Notion, run a Jira intake project, add JPD, or adopt enforced states — the case for each, stated first. - [The engineering intake process, end to end](https://www.deliverysheet.com/blog/engineering-intake-process) The work intake process for an engineering team: one door, two questions, four recorded exits. No triage committee, no twelve-field form. - [Not every request should enter the process](https://www.deliverysheet.com/blog/not-every-request-is-a-demand) A bar at intake is usually described as bureaucracy. One sentence wide, applied at the door, it is the cheapest quality control a delivery process has. ```json {"@context":"https://schema.org","@graph":[{"@id":"https://www.deliverysheet.com/#website","@type":"WebSite","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date. AI-assisted shaping, planning and commitment governance for engineering leaders.","name":"DeliverySheet","url":"https://www.deliverysheet.com/","publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#webpage","dateModified":"2026-10-10","datePublished":"2026-10-10","description":"An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list.","name":"Platform team intake: handling requests","url":"https://www.deliverysheet.com/blog/platform-team-intake","@type":["WebPage","FAQPage"],"breadcrumb":{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#breadcrumb"},"isPartOf":{"@id":"https://www.deliverysheet.com/#website"},"mainEntity":[{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#/schema/question/1"}],"potentialAction":[{"@type":"ReadAction","target":["https://www.deliverysheet.com/blog/platform-team-intake"]}],"primaryImageOfPage":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/#identity","@type":"Organization","alternateName":"Delivery Sheet","description":"Turn raw work requests into structured, decision-ready demands before you commit people, budget, or a date.","name":"DeliverySheet","url":"https://www.deliverysheet.com","founder":{"@type":"Person","@id":"https://www.deliverysheet.com/about#person","name":"Tan Gravam"},"logo":{"@id":"https://www.deliverysheet.com/#logo"}},{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#breadcrumb","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","name":"Home","item":"https://www.deliverysheet.com","position":1},{"@type":"ListItem","name":"Writing","item":"https://www.deliverysheet.com/blog","position":2},{"@type":"ListItem","name":"How a platform team should take requests from other teams","item":"https://www.deliverysheet.com/blog/platform-team-intake","position":3}]},{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#article","@type":"Article","dateModified":"2026-10-10","datePublished":"2026-10-10","description":"An intake process for platform, data and other shared teams: split support from change requests, ask for the need, decide weekly and publish the list.","headline":"How a platform team should take requests from other teams","inLanguage":"en","thumbnailUrl":"https://www.deliverysheet.com/_og/s/o_900ca048703b0d77.png","author":{"@id":"https://www.deliverysheet.com/about#person"},"image":{"@id":"https://www.deliverysheet.com/#/schema/image/1"},"isPartOf":{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#webpage"},"keywords":["intake","process design","engineering management"],"mainEntityOfPage":{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#webpage"},"publisher":{"@id":"https://www.deliverysheet.com/#identity"}},{"@id":"https://www.deliverysheet.com/blog/platform-team-intake#/schema/question/1","@type":"Question","inLanguage":"en","name":"How should a platform team handle requests from other teams?","acceptedAnswer":{"@type":"Answer","text":"A platform team should handle requests from other teams through two doors. Support, meaning something is broken or someone needs help, goes to a weekly rotation and one channel and is answered the same day. Requests for the platform to change go through an intake that asks three things: what the team is trying to do, what it costs them while it stays as it is, and whether a date is attached. Once a week every request gets one of four answers in writing: planned, a short look first, not now with a review date, or no with the reason. Publish the committed, parked and declined lists so requesting teams can see each other. When two teams both need something first, someone above both sets the order."}},{"@id":"https://www.deliverysheet.com/about#person","@type":"Person","jobTitle":"Founder","name":"Tan Gravam","url":"https://www.deliverysheet.com/about","sameAs":["https://gravam.com","https://twitter.com/TanGravam","https://github.com/TanGravam"]},{"@id":"https://www.deliverysheet.com/#logo","@type":"ImageObject","caption":"DeliverySheet","contentUrl":"https://www.deliverysheet.com/logo.png","inLanguage":"en","url":"https://www.deliverysheet.com/logo.png"},{"@id":"https://www.deliverysheet.com/#/schema/image/1","@type":"ImageObject","contentUrl":"https://www.deliverysheet.com/_og/s/o_900ca048703b0d77.png","inLanguage":"en","url":"https://www.deliverysheet.com/_og/s/o_900ca048703b0d77.png"}]} ``` ## Sitemap See the full [sitemap](https://www.deliverysheet.com/sitemap.md) for all pages.