Skapa en webbapp för att hantera kommunikationsförfrågningar mellan team

Definiera problemet och omfattningen

Innan du bygger något, var konkret med vad du försöker åtgärda. “Kommunikation mellan team” kan innebära allt från ett snabbt meddelande i Slack till en fullständig produktlanseringskommunikation. Om omfattningen är vag kommer appen antingen att bli en dumpningsplats — eller så kommer ingen använda den.

Vad menas med en “kommunikationsförfrågan” här?

Skriv en enkel definition som folk kan komma ihåg, plus några exempel och icke-exempel. Typiska förfrågningsstyper inkluderar:

• Kundinriktade tillkännagivanden (underhåll, policyändringar)
• Godkännanden för supportsvar i känsliga fall
• Release notes och ändringsloggar
• Uppdateringar för försäljning (ny prissättning, positionering)
• Utsagor som granskats av ledning eller juridik

Dokumentera också vad som inte hör hemma här (t.ex. ad‑hoc brainstorming, allmänna FYI‑uppdateringar eller “kan du hoppa in på ett samtal?”). En tydlig avgränsning förhindrar att systemet blir en generell inkorg.

Vilka är involverade och vilken roll har de?

Lista de team som berörs av förfrågningar och vilket ansvar varje har:

• Begäraren (skickar in behovet, lämnar kontext och tillgångar)
• Godkännaren (bekräftar prioritet, risk, efterlevnad och budskap)
• Utföraren (skriver/producerar innehållet, publicerar eller skickar)
• Granskaren (sista kontroll för faktakontroll, ton och varumärke)

Om en roll varierar efter förfrågningskategori (t.ex. juridik endast för vissa ämnen), fånga det nu — det kommer styra routningsregler senare.

Hur vet du att det fungerade?

Välj några mätbara utfall, till exempel:

• Färre “någon uppdatering?”‑frågor i chatten
• Kortare tid från inskick till publicering
• Färre missade eller dubbla förfrågningar

Skriv slutligen dagens smärtpunkter enkelt: oklart ägarskap, saknad information, sista‑minuten‑förfrågningar och förfrågningar gömda i DM. Detta blir din baslinje — och din motivering till förändring.

Kartlägg arbetsflödet och användarberättelser

Innan du bygger, få intressenterna överens om hur en förfrågan rör sig från “någon behöver hjälp” till “arbete levererat.” En enkel arbetsflödeskarta förhindrar oavsiktlig komplexitet och visar var överlämningar ofta bryter.

Användarberättelser (håll dem specifika)

Här är fem startberättelser du kan anpassa:

• Som begäraren skickar jag in en kort brief och ser direkt vem som äger den och när jag kan förvänta mig ett slutdatum.
• Som triageansvarig kan jag snabbt validera förfrågan, ställa en uppföljningsfråga eller avslå den med en tydlig anledning.
• Som godkännare kan jag granska förfrågan, godkänna/avslå och lämna en kommentar som blir en del av registret.
• Som schemaläggare/publisher kan jag lägga godkänt arbete i en kalender, upptäcka krockar och bekräfta publiceringsdatum.
• Som intressent kan jag följa status och uppdateringar utan att jaga folk i chatten.

Kartlägg förfrågans livscykel

Ett vanligt livscykelmönster för en hanteringsapp för kommunikationsförfrågningar ser ut så här:

skicka in → triage → granska → godkänna → schemalägga → publicera → avsluta

För varje steg, skriv ner:

• Inträdeskriterier (vad som måste vara sant för att starta)
• Ägare (person eller roll)
• Förväntat resultat (vad “klart” innebär)
• Tillåtna exit‑vägar (gå vidare, returnera för redigering, avvisa)

Konfigurerbara vs fasta beslut

Gör dessa konfigurerbara: team, kategorier, prioriteringar och intagsfrågor per kategori. Behåll fasta (åtminstone initialt): kärnstatusarna och definitionen av “avslutad.” För mycket konfigurerbarhet tidigt gör rapportering och utbildning svårare.

Högst riskfyllda steg att designa noggrant

Var uppmärksam på felpunkter: godkännanden som stagnerar, schemaläggningskrockar över kanaler och efterlevnads/juridiska granskningar som kräver revisionsspår och strikt ägarskap. Dessa risker bör direkt forma dina regler för arbetsflöde och statusövergångar.

Designa intagsformuläret (få rätt information från början)

En förfrågningsapp fungerar bara om intagsformuläret konsekvent fångar en användbar brief. Målet är inte att fråga efter allt — utan att fråga efter rätt saker så att ditt team slipper spendera dagar på att jaga klarheter.

Börja med en minimalt gångbar brief

Håll första skärmen tight. Som minimum, samla in:

• Titel på förfrågan (enmeningssammanfattning)
• Beskrivning (vad du behöver och varför)
• Målgrupp (vem ska få detta)
• Kanal (e‑post, in‑app, socialt, press osv.)
• Önskat datum (när det måste gå ut)
• Bifogade filer (utkast, kreativa tillgångar, skärmbilder, juridiska anteckningar)

Lägg till kort hjälpsam text under varje fält, t.ex.: “Målgruppsexempel: ‘Alla US‑kunder på Pro‑planen’.” Dessa mikroexempel minskar fram‑och‑tillbaka mer än långa riktlinjer.

Lägg till hjälpsamma fält som förhindrar omarbete

När grunderna sitter, inkludera fält som gör prioritering och samordning enklare:

• Prioritet (t.ex. Låg/Medel/Hög)
• Affärspåverkan (vad som förändras om detta inte genomförs)
• Länkar (PRD, Jira‑ärende, analys, varumärkesdokument)
• Intressenter (godkännare och informerade parter)
• Språk/region (om lokalisering eller regionala regler gäller)

Använd villkorliga frågor för att hålla det kort och heltäckande

Villkorslogik håller formuläret lätt. Exempel:

• Om Kanal = Press, fråga efter talesperson, embargodatum och medielista.
• Om Målgrupp inkluderar kunder, fråga efter segmenteringskriterier och supportberedskap.

Validera för fullständighet (utan att vara irriterande)

Använd tydliga valideringsregler: obligatoriska fält, datum kan inte vara i det förflutna, bilagor krävs för “Hög” prioritet och minimilängd för beskrivningen.

När du avvisar en inlämning, returnera den med specifik vägledning (t.ex. “Lägg till målgrupp och länk till källa”), så lär sig begärarna standarden över tid.

Skapa statusar, ägarskap och tydliga regler

En förfrågningshanteringsapp fungerar bara när alla litar på statusen. Det innebär att appen måste vara den enda sanningskällan — inte en “verklig status” gömd i sidokonversationer, DM eller e‑posttrådar.

Definiera ett enkelt, gemensamt statusset

Håll statusarna få, entydiga och kopplade till handlingar. Ett praktiskt standardset för kommunikationsförfrågningar är:

• Ny — inskickad och väntar på triage
• Behöver info — blockerad tills begäraren lämnar saknad information
• I granskning — utvärderas för genomförbarhet, prioritet eller policy
• Godkänd — accepterad och redo att planeras
• Schemalagd — tilldelad ett datum/tid eller sprint
• Klart — levererat och stängt
• Avslagen — avvisad med inspelad anledning

Nyckeln är att varje status svarar på: Vad händer härnäst, och vem väntar på vem?

Tilldela ägare per steg (så inget flyter omkring)

Varje status bör ha en tydlig “ägare”‑roll:

• Triageansvarig (ofta en rullande on‑call) säkerställer att varje Ny förfrågan hanteras snabbt.
• Godkännare fattar beslutet go/no‑go under I granskning.
• Assignee/utförare ansvarar för leverans när något är Godkänt/Schemalagt.

Ägarskap förhindrar det vanliga felmönstret där alla är “involverade” men ingen är ansvarig.

Skriv regler som förhindrar statuskaos

Lägg in lättviktiga regler direkt i appen:

• Vem kan flytta en förfrågan (t.ex. bara triage kan flytta ut ur Ny; endast godkännare kan sätta Godkänd/Avslagen).
• När den kan återöppnas (t.ex. tillåt återöppning från Klart endast inom 14 dagar och kräva en anledning).
• Vad som krävs per övergång (t.ex. flytta till Schemalagd kräver ett datum; flytta till Avslagen kräver motivering).

Dessa regler håller rapporteringen korrekt, minskar fram‑och‑tillbaka och gör överlämningar mellan team förutsägbara.

Planera datamodellen och nyckelfält

En tydlig datamodell håller ditt förfrågningssystem flexibelt när nya team, förfrågningsstyper och godkännandesteg dyker upp. Sikta på ett litet antal kärntabeller som kan stödja många arbetsflöden, istället för att skapa ett nytt schema för varje team.

Kärntabeller (börja enkelt)

Som minimum, planera dessa:

• Users: namn, e‑post, roll, aktiv‑flagga
• Teams: teamnamn, standard‑SLA‑policy, routningsregler
• Requests: själva “ticketen” (detaljer nedan)
• Comments: trådad diskussion knuten till en förfrågan
• Attachments: filer eller länkar, med uppladdare och tidsstämpel
• StatusHistory: varje statusändring (och helst även ägarändringar)

Denna struktur stödjer överlämningar mellan team och gör rapportering mycket enklare än att förlita sig på enbart “aktuellt tillstånd.”

Nyckelfält på Request‑posten

Din Requests‑tabell bör fånga routning och ansvar på ett grundläggande sätt:

• requesting_team och/eller requester_user
• category (kampanj, tillkännagivande, press, juridisk granskning osv.)
• priority (eller påverkan/brådska)
• due_date (vad begäraren behöver)
• sla_target_at (beräknat deadline baserat på SLA‑policy)
• current_status
• current_owner_user (eller ägarteam + uppdragstagare)

Överväg även: sammanfattning/titel, beskrivning, önskade kanaler (e‑post, Slack, intranät) och nödvändiga tillgångar.

Taggar + sök för verklig filtrering

Lägg till taggar (många‑till‑många) och ett searchable_text‑fält (eller indexerade kolumner) så team kan filtrera köer snabbt och rapportera trender (t.ex. “product‑launch” eller “executive‑urgent”).

Auditbarhet är inte valfritt

Planera för revisionsbehov från start:

• Spara created_at / updated_at / closed_at tidsstämplar
• Behåll StatusHistory med vem ändrade vad, när
• Bevara tidigare värden för kritiska fält (status, ägare, datum)

När intressenter frågar “Varför var detta försenat?” har du ett tydligt svar utan att gräva i chattloggar.

Designa huvudskärmarna och navigation

Bra navigation är inte dekoration — det förhindrar att “Var kollar jag detta?”‑meddelanden blir det verkliga arbetsflödet. Designa vyer kring de roller folk naturligt tar i förfrågningsarbete, och håll varje vy fokuserad på nästa åtgärd.

Begärarvyn (skicka in och följa upp)

Upplevelsen för begäraren ska kännas som att spåra ett paket: tydlig, lugn och alltid aktuell. Efter inlämning, visa en enkel förfrågningssida med status, ägare, måldatum och nästa förväntade steg.

Gör det enkelt att:

• Skicka in en förfrågan och bifoga tillgångar
• Se framsteg över tid (en enkel tidslinje funkar)
• Svara snabbt på Behöver info med kommentarer/filer
• Få uppdateringar utan att leta (e‑post + in‑app)

Triagevyn (kö och beslut)

Detta är kontrollrummet. Standardisera en kö‑instrumentpanel med filter (team, kategori, status, prioritet) och bulkåtgärder.

Inkludera:

• En prioriterad kö med synlig “tid i status”
• Snabbtilldelning och omfördelning
• Duplicatdetektion (matcha på titel + begärande + länkar)
• Prioritets‑ och förfallodatumkontroller utan att öppna varje förfrågan

Utförarvyn (gör jobbet)

Utförare behöver en personlig arbetsbelastningsskärm: “Vad är mitt, vad är nästa, vad är i riskzonen?” Visa kommande deadlines, beroenden och en checklista för tillgångar för att undvika onödiga rundor fram och tillbaka.

Adminvyn (konfigurera utan att bryta flödet)

Administer bör hantera team, kategorier, behörigheter och SLA:er från en inställningsyta. Håll avancerade alternativ en klickning bort och ge säkra standardinställningar.

Navigation som förblir konsekvent

Använd en vänster‑nav (eller toppflikar) som speglar rollbaserade områden: Förfrågningar, Kö, Mitt arbete, Rapporter, Inställningar. Om en användare har flera roller, visa alla relevanta sektioner men låt första skärmen vara roll‑anpassad (t.ex. triagers landar på Kö).

Behörigheter, säkerhet och auditbarhet

Behörigheter är inte bara ”IT‑krav” — de förhindrar oavsiktlig översharing och håller förfrågningar i rörelse utan förvirring. Börja enkelt och skärp efterhand när du lär dig vad team faktiskt behöver.

Rollbaserad åtkomst (håll det förutsägbart)

Definiera ett litet set roller och gör varje roll uppenbar i gränssnittet:

• Begäraren: kan skicka in, se sina egna förfrågningar, svara på frågor och se status.
• Teammedlem (utförare): kan se sin teams kö, kommentera, begära ändringar och uppdatera status.
• Godkännare: kan godkänna/avslå specifika steg (t.ex. kommunikationssign‑off eller juridisk granskning).
• Admin: hanterar mallar, fält, team och behörighetsregler.

Undvik “specialfall” i början. Om någon behöver extra åtkomst, behandla det som en rolländring — inte ett engångstillstånd.

Skydda känsliga förfrågningar utan att sakta ner alla

Använd team‑baserad synlighet som standard: en förfrågan är synlig för begäraren plus de tilldelade teamen. Lägg sedan till två alternativ:

• Privata fält (t.ex. budget, medarbetardetaljer) synliga endast för specifika roller.
• Begränsade förfrågningar där endast en namngiven grupp kan komma åt hela registret.

Detta håller det mesta arbete öppet samtidigt som kantfallen skyddas.

Bestäm hur gäster fungerar (om några)

Om ni behöver externa granskare eller tillfälliga intressenter, välj en modell:

• Visningslänkar med utgångsdatum (bra för att dela ett slutgiltigt utkast).
• Krävda konton (bättre för godkännanden, kommentarer och spårbarhet).

Att blanda båda kan fungera, men dokumentera när varje modell är tillåten.

Auditbarhet: gör ansvar automatiskt

Logga viktiga åtgärder med tidsstämpel och aktör: statusändringar, redigeringar av kritiska fält, godkännanden/avslag och slutlig publiceringsbekräftelse. Gör revisionsspåret lätt att exportera för efterlevnad och tillräckligt synligt för att team ska lita på historiken utan att behöva “fråga runt”.

Aviseringar och påminnelser som inte skapar brus

Aviseringar bör föra en förfrågan framåt — inte skapa en andra inkorg som folk lär sig ignorera. Målet är enkelt: berätta rätt sak för rätt person i rätt tid, med ett tydligt nästa steg.

Avisera endast vid nyckelhändelser i arbetsflödet

Börja med ett kort set händelser som direkt ändrar vad någon bör göra härnäst:

• Inskickad (bekräftelse till begäraren + “vad händer härnäst”)
• Tilldelad (ägare får kontext + länk till förfrågan)
• Behöver info (begäraren får specifika frågor och en deadline)
• Godkänd/avslagen (begäraren + downstream‑team vid behov)
• Snart förfallodag och försenad (ägare + valfri eskalering till chef)

Om en händelse inte kräver åtgärd, behåll den i aktivitetsloggen istället för att skicka en avisering.

Välj 1–2 kanaler och gör dem bra

Undvik att sprida uppdateringar överallt. De flesta team lyckas genom att börja med en primär kanal (ofta e‑post) plus en realtidskanal (Slack/Teams) för ägare.

En praktisk regel: använd realtid för arbete du äger och e‑post för synlighet och register. In‑app‑aviseringar blir användbara när folk bor i verktyget dagligen.

Påminnelseregler som minskar brus

Påminnelser ska vara förutsägbara och konfigurerbara:

• Dagliga eller tvådagars sammandrag för “behöver info” och “väntar på dig”‑ärenden
• Tysta timmar (inga pings efter arbetstid; skicka nästa morgon)
• Eskalera endast efter en tydlig tröskel (t.ex. 48 timmar försenad)

Använd mallar så uppdateringar är handlingsbara

Mallar håller meddelanden konsekventa och lätta att skanna. Varje avisering bör innehålla:

• Förfrågans titel + ID
• Aktuell status och ägare
• Vad som ändrats
• En tydlig CTA‑länk (t.ex. “Lägg till info”, “Granska”, “Markera klar”)

Detta gör varje meddelande meningsfullt — snarare än ett brus.

SLA:er, förfallodatum och schemaläggning

Om förfrågningar inte levereras i tid är orsaken ofta oklara förväntningar: “Hur lång tid borde detta ta?” och “Till när?” Bygg tidshantering i arbetsflödet så att det är synligt, konsekvent och rättvist.

Definiera SLA:er per förfrågningskategori

Sätt servicenivåförväntningar som matchar arbetets omfattning. Till exempel:

• Tillkännagivanden: 5 arbetsdagar
• Nyhetsbrevsposter: 3 arbetsdagar
• Exekutiva kommunikationer: 10 arbetsdagar

Gör SLA‑fältet fältdrivet: i samma stund som en begäran väljer typ visar appen förväntad ledtid och tidigaste genomförbara publiceringsdatum.

Beräkna mål‑datum automatiskt

Undvik manuell huvudräkning. Spara två datum:

• Önskat publiceringsdatum (vad begäraren vill)
• Måldatum för slutförande (vad teamet förbinder sig till)

Beräkna sedan måldatumet med hjälp av förfrågningstypens ledtid (arbetsdagar) och eventuella nödvändiga steg (t.ex. godkännanden). Om någon ändrar publiceringsdatumet ska appen omedelbart uppdatera måldatumet och flagga “tajt tidslinje” när begärarens datum är tidigare än det tidigast möjliga datumet.

Schemaläggning för att förhindra kollisioner

En kö ensam visar inte konflikter. Lägg till en enkel kalender/schemavy som grupperar objekt efter publiceringsdatum och kanal (e‑post, intranät, socialt osv.). Detta hjälper team att upptäcka överbelastning (för många utskick på tisdag) och förhandla alternativ innan arbete startar.

Spåra orsaker till förseningar

När en förfrågan halkar efter, fånga en enda “förseningorsak” så rapporteringen blir åtgärdsbar: väntar på begäraren, väntar på godkännanden, kapacitet eller omfattningsändring. Med tiden blir missade deadlines till mönster som går att åtgärda istället för återkommande överraskningar.

Bygg en MVP och välj en praktisk teknisk strategi

Det snabbaste sättet att skapa värde är att leverera en liten, användbar MVP som ersätter ad‑hoc‑chattar och kalkylblad — utan att försöka lösa varje kantfall.

Starta med en MVP som folk faktiskt kommer använda

Sikta på minsta funktioner som stöder en komplett förfrågningslivscykel:

• Ett intagsformulär som fångar det väsentliga (förfrågningstyp, målgrupp, deadline, prioritet, bilagor)
• En delad förfrågningskö (en plats att se “vad väntar”)
• Enkla statusar anpassade till ditt arbetsflöde (till exempel: Ny → I granskning → Godkänd → Schemalagd → Klart, med Behöver info och Avslagen som sidovägar)
• Kommentarer och @omnämnanden för förtydliganden
• Grundläggande aviseringar (bekräftelse till begäraren, tilldelning till ägare, statusändringar)

Om du gör detta väl kommer du omedelbart att minska fram‑och‑till‑baks och skapa en enda sanningskälla.

Välj en stack som passar ditt team (inte din önskelista)

Välj den approach som matchar era färdigheter, leveranshastighet och styrning:

• Low‑code (snabbast leverans): bra för formulär + godkännanden + enkla dashbord.
• Plattformar för interna verktyg: starka för autentiserade appar med tabeller, filter och adminpaneler.
• Fullstack‑bygg: bäst när du behöver kundanpassade integrationer, komplexa behörigheter eller tung automation.

Om ni vill accelerera fullstack‑vägen utan att återgå till sköra kalkylblad kan plattformar som Koder.ai vara användbara för att få fram en fungerande internapp från en strukturerad chatt‑spec. Ni kan prototypa intagsformuläret, kön, roller/behörigheter och dashboards snabbt, och sedan iterera med intressenter — samtidigt som ni håller möjligheten att exportera källkod och distribuera enligt era egna policyer.

Implementera sök och filter tidigt

Redan vid 50–100 förfrågningar behöver folk skära i kön efter team, status, förfallodatum och prioritet. Lägg till filter från dag ett så verktyget inte blir en lång scroll‑lista.

Lägg till analys senare (när datan är ren)

När arbetsflödet är stabilt, bygg på rapportering: genomströmning, cykeltid, backlogstorlek och SLA‑uppfyllnadsgrad. Du får bättre insikter när team konsekvent använder samma statusar och datumregler.

Lansering, adoption och itereringsplan

En förfrågningshanteringsapp fungerar bara om folk faktiskt använder den — och fortsätter använda den. Behandla första releasen som en lärandefas, inte en storslagen utrullning. Målet är att etablera den nya “sanningskällan” för kommunikationsförfrågningar och sedan förbättra arbetsflödet utifrån verkligt beteende.

Börja med en liten pilot

Pilota med 1–2 team och 1–2 förfrågningskategorier. Välj team som har frekventa överlämningar och en chef som kan förstärka processen. Håll volymen hanterbar så ni kan svara snabbt på problem och bygga förtroende.

Under piloten, kör det gamla förfarandet parallellt endast när det är absolut nödvändigt. Om uppdateringar fortsätter ske i chatten eller e‑post kommer appen aldrig bli standard.

Publicera lätta riktlinjer

Skapa enkla riktlinjer som svarar på:

• Vad som bör skickas in (och vad som inte bör skickas)
• Obligatorisk ledtid (t.ex. “72 timmar för standardärenden”)
• Var uppdateringar bor (appen, inte DM)

Fäst riktlinjerna i ert team‑nav och länka till dem från appen (till exempel, /help/requests). Gör dem tillräckligt korta för att folk faktiskt läser dem.

Bygg en feedback‑loop som ni kan agera på

Samla feedback veckovis från begärarna och ägarna. Fråga specifikt om saknade fält, förvirrande statusar och notis‑spam. Para detta med en snabb granskning av verkliga förfrågningar: var tvekade folk, övergav eller kringgick arbetsflödet?

Iterera utan att bryta vanor

Iterera i små, förutsägbara förändringar: justera formulärfält, SLA:er och behörigheter baserat på verklig användning. Meddela ändringar på ett ställe, med en “vad ändrades / varför”‑anteckning. Stabilitet bygger adoption; ständig omarbetning undergräver den.

Om ni vill att detta ska hålla, mät adoption (förfrågningar inskickade via appen vs utanför), cykeltid och omarbete. Använd sedan resultaten för att prioritera nästa iteration.

Mät resultat och förbättra över tid

Att lansera din förfrågningshanteringsapp är inte mållinjen — det är början på en feedbackloop. Om du inte mäter systemet kan det långsamt bli en “svart låda” där team slutar lita på statusar och återvänder till sidomeddelanden.

Börja med dashboards folk faktiskt använder

Skapa ett litet set vyer som svarar på dagliga frågor:

• Öppna förfrågningar (vad som finns i kön just nu)
• Försenade (förbi förfallodatum eller SLA)
• Kommande (snart förfallodatum så team kan planera)
• Arbetsbelastning per team/ägare (för att upptäcka flaskhalsar och ojämn fördelning)

Håll dessa dashboards synliga och konsekventa. Om team inte förstår dem på 10 sekunder kommer de inte kolla dem.

Granska mått månadsvis — och besluta vad som ska ändras

Välj ett återkommande månatligt möte (30–45 minuter) med representanter från huvudteam. Använd det för att granska en kort, stabil uppsättning mått, som:

• Genomsnittlig tid till första svar
• Genomsnittlig tid till slutförande
• SLA‑uppfyllnadsgrad
• Återöppningsgrad (förfrågningar som studsar tillbaka)
• Volym per förfrågningskategori

Avsluta mötet med specifika beslut: justera SLA:er, förtydliga intagsfrågor, raffinera statusar eller ändra ägarskapsregler. Dokumentera förändringar i en enkel ändringslogg så folk vet vad som skiljer.

Behåll en lättviktig taxonomi

En taxonomi är bara användbar om den hålls liten. Sikta på ett fåtal kategorier plus valfria taggar. Undvik att skapa hundratals typer som kräver ständig vakthållning.

Planera förbättringar baserat på bevis

När grunderna är stabila, prioritera förbättringar som minskar manuellt arbete:

• Mallar för återkommande förfrågningar
• Integrationer (chatt, e‑post, kalender, ärendehantering)
• Policydrivna godkännanden (endast när det behövs)
• Ett API för rapportering eller att skapa förfrågningar från andra verktyg

Låt användning och mätvärden — inte åsikter — bestämma vad ni bygger nästa gång.