12 nov. 2025·8 min
Så bygger du en webbapp för kampanjer med klientgodkännanden
Lär dig planera och bygga en webbapp för marknadsföringsbyråer som hanterar kampanjer, assets och kundgodkännanden, med roller, arbetsflöden och revisionsbar historik.
Lär dig planera och bygga en webbapp för marknadsföringsbyråer som hanterar kampanjer, assets och kundgodkännanden, med roller, arbetsflöden och revisionsbar historik.
Innan du skissar skärmar eller väljer teknikstack, bli tydlig med kärnproblemet: kampanjer och godkännanden är utspridda över e-post, chatt och delade diskar. En kampanjwebbapp bör samla briefar, assets, feedback och sign-off på ett ställe så att alla kan se vad som händer härnäst—utan att jaga trådar.
De flesta byråers godkännandearbetsflöden involverar fyra grupper med olika behov:
E-postbaserade godkännanden skapar förutsägbara problem: missade deadlines för att ingen ser den senaste förfrågan, otydlig feedback som “gör det mer levande” utan konkretion, flera versioner som flyter omkring, och omarbetningar orsakade av sena eller motstridiga inlägg.
Definiera mätbara utfall så att du kan avgöra om produkten fungerar:
För v1, fokusera på minsta möjliga uppsättning som håller kampanjer och godkännanden tillsammans:
Spara trevliga-att-ha-funktioner till senare: avancerad rapportering, djupa integrationer, automationsregler och anpassade godkännandepassager.
Innan du tänker på skärmar eller teknik, skriv ner hur arbete faktiskt flödar genom din byrå. Ett tydligt arbetsflöde förvandlar “Var är detta?” till en förutsägbar uppsättning steg som din app kan upprätthålla, automatisera och rapportera om.
De flesta kampanjgodkännandeappar kan beskrivas med en liten uppsättning byggstenar:
Dokumentera relationerna: en kampanj innehåller projekt; projekt innehåller uppgifter; uppgifter producerar assets; assets går igenom godkännanden.
Ett enkelt, byråvänligt flöde är:
Draft → Internal review → Client review → Approved
Låt varje tillstånd betyda något operationellt. Till exempel kan “Internal review” kräva sign-off från kreativitetsansvarig och account manager innan kunden ser det.
Bestäm hur feedback ser ut i din produkt:
Nyckeln är att knyta feedback till en asset-version, så att man inte behöver argumentera om vilken fil kunden granskade.
Vanliga fördröjningar: väntan på granskare, otydliga nästa steg och upprepad setup. Automatisering som hjälper mest:
Verkliga godkännanden är inte alltid rena. Planera för:
Om du kan beskriva dessa regler i klartext är du redo att omvandla dem till skärmar och datamodeller.
Bra UX för en kampanjapp börjar med en enkel informationshierarki som speglar hur byråer redan tänker: Client → Campaign → Deliverables (assets). Om användare alltid kan svara på “Var är jag?” och “Vad händer härnäst?”, går godkännanden snabbare och färre saker faller mellan stolarna.
Använd klienten som översta ankaret, visa sedan kampanjer under och slutligen leverabler (annonser, e-post, landningssidor, sociala inlägg). Behåll samma struktur i navigering, brödsmulor och sök så att folk inte behöver lära om appen på varje skärm.
En praktisk regel: varje leverabel ska alltid visa sin klient, kampanj, förfallodatum, status och ägare vid en blick.
Dashboard: Byråns hem. Fokusera på vad som kräver uppmärksamhet idag: kommande förfallodatum, objekt som väntar intern granskning och objekt som väntar på kundgodkännande.
Kampanjtidslinje: En kalenderlik eller fasbaserad vy som gör beroenden tydliga (t.ex. “Copy godkänd” före “Design final”). Håll det läsbart—folk ska förstå framsteg på några sekunder.
Asset review view: Här vinns eller förloras tid. Gör förhandsvisningen stor, kommentarerna lätta att hitta och nästa åtgärd tydlig.
Inbox: Ett enhetligt ställe för “saker jag måste svara på” (ny feedback, godkännandeförfrågningar, omnämnanden). Detta minskar ping-pong över e-post och chatt.
Snabbfilter bör svara på vanliga byråfrågor:
Huvud-CTA bör vara uppenbar: Approve / Request changes. Håll den fast i granskningsvyn (klibbig footer/header) så att kunder inte letar efter den efter att ha skrollat igenom kommentarer.
Kunder granskar ofta mellan möten. Prioritera mobil läsbarhet: ren förhandsvisning, stora knappar och korta formulär för feedback. Om ett tryck kan öppna asset och ett annat godkänna, ser du snabbare omloppstider.
En kampanjgodkännandeapp lever eller dör på förtroende: kunder måste känna sig säkra på att de bara ser vad de ska, och ditt team behöver tydliga gränser så att arbete inte skrivs över eller godkänns av fel person.
De flesta byråer täcker behoven med fem roller:
Istället för enbart globala behörigheter, definiera åtgärder per objekttyp (campaign, deliverable, asset, comment). Typiska åtgärder inkluderar view, comment, upload, approve, edit, och delete.
Ett praktiskt standardval är “least privilege”: contributors kan ladda upp och redigera sina egna assets, men radering eller ändring av kampanjinställningar är begränsat till account managers/admins.
Kunder ska bara se sina kampanjer, assets och diskussioner. Undvik delade “kundmappar” som av misstag exponerar andra konton. Detta är enklast när varje kampanj är knuten till ett kundkonto och åtkomstkontroller tillämpas konsekvent över sidor, nedladdningar och aviseringar.
Stöd två godkännandelägen per leverabel:
Erbjud delningslänkar för bekvämlighet, men håll dem privata som standard: tidsbegränsade tokens, valfritt lösenord och möjlighet att ångra åtkomst.
En bra regel: delning får aldrig kringgå kundgränsen—det ska bara ge åtkomst till objekt användaren normalt sett kan se.
En klientgodkännande-funktion lever eller dör på tydlighet. Om ditt team och kunder inte kan avgöra vem som väntar på vad, stannar godkännanden av och “godkänd” blir diskutabelt.
Börja med ett litet set tillstånd som alla känner igen:
Undvik att lägga till ett nytt status för varje kantfall. Om du behöver mer nyans, använd taggar (t.ex. “legal review”) snarare än att spränga workflowen.
Behandla varje uppladdning som en ny immutabel version. Ersätt inte filer på plats—skapa v1, v2, v3… kopplade till samma asset.
Detta stödjer rena konversationer (“Vänligen uppdatera v3”) och förhindrar oavsiktlig förlust. I UI, gör den aktuella versionen tydlig och låt granskare öppna tidigare versioner för jämförelse.
Friformskommentarer blir röriga. Lägg till struktur:
Om du stöder tidskoder (video) eller sida/region-pinnar (PDF/bilder) blir feedback dramatiskt mer handlingsbar.
När någon godkänner, spela in:
Efter godkännande, definiera reglerna: vanligtvis lås redigering av den godkända versionen, men tillåt att skapa en ny mindre revision som ny version (vilket återställer status till In Review). Detta håller godkännanden försvarbara utan att blockera legitima sista minuten-ändringar.
Kreativa godkännanden lever eller dör på hur enkelt folk kommer åt rätt fil vid rätt tidpunkt. Asset-hantering är där många kampanjappar i tysthet blir frustrerande—långsamma nedladdningar, förvirrande filnamn och oändliga “vilken version är slutgiltig?”-loopar.
Ett rent mönster är: objektlagring för de faktiska filerna (snabbt, skalbart, billigt) och en databas för metadata (sökbar och strukturerad).
Din databas bör spåra saker som: asset-namn, typ, kampanj, aktuell version, vem som laddade upp, tidsstämplar, godkännandestatus och förhandsvisnings-URL:er. Lagringslagret håller binära filer och eventuellt härledda objekt som thumbnails.
Sikta på en liten uppsättning som täcker de flesta arbetsflöden:
Var tydlig i UI vad som är uppladdningsbart vs länkbart. Det minskar misslyckade uppladdningar och supportärenden.
Förhandsvisningar gör granskning snabbare och mer kundvänlig. Generera:
Detta låter intressenter överblicka en dashboard med leverabler utan att ladda ner fullupplösta filer.
Definiera filgränser tidigt (maxstorlek, maxantal per kampanj, stödda filändelser). Validera både filtyp och innehåll (lita inte på ändelser). Om du arbetar med företagskunder eller accepterar stora filer, överväg virus-/malwareskanning i uppladdningspipen.
Godkännanden kräver ofta spårbarhet. Bestäm vad “radera” betyder:
Para detta med policys (t.ex. behåll assets i 12–24 månader efter kampanjslut) så att lagringskostnader inte växer utan plan.
En kampanjapp med klientgodkännanden behöver inte exotisk infrastruktur. Den behöver tydliga gränser: ett användarvänligt gränssnitt för människor, ett API som upprätthåller regler, lagring för filer och data, och bakgrundsjobb för tidsbaserat arbete som påminnelser.
Börja med det ert team kan bygga och drifta säkert. Om ni redan kan React + Node, eller Rails, eller Django, är det oftast rätt val för v1. Hostingpreferenser spelar också roll: om du vill ha “push to deploy”-enkelhet, välj en plattform som stöder din stack och gör loggar, skalning och hemligheter okomplicerade.
Om du vill iterera snabbare utan tungt bygg-från-grunden-arbete kan en vibe-coding-plattform som Koder.ai hjälpa dig att prototypa och iterera på arbetsflödet (kampanjer, assets, godkännanden, roller) via en chattdriven yta—och sedan exportera källkoden när du vill ta över.
Frontend (webbapp): Dashboards, kampanjtidslinjer och granskningsskärmar. Den pratar med API:et och hanterar realtids-UX-detaljer (laddstatus, uppladdningsprogress, kommentarstrådar).
Backend API: Sanningskällan för affärsregler—vem kan godkänna, när en asset är låst, vilka statusövergångar som tillåts. Håll det enkelt och förutsägbart.
Databas: Sparar kampanjer, uppgifter, godkännanden, kommentarer och audit-händelser.
Fil-lagring + förhandsvisning: Spara uppladdningar i objektlagring (t.ex. S3-kompatibel). Generera thumbnails/förhandsvisningar så att klienter kan granska utan att ladda ner stora filer.
Bakgrundsjobb: Allt som inte ska blockera användaren: skicka mejl, generera förhandsvisningar, schemalagda påminnelser, nattliga rapporter.
För de flesta byråer är en modulär monolit idealisk: en backendkodbas med väl separerade moduler (assets, godkännanden, aviseringar). Du kan fortfarande lägga till tjänster där de verkligen hjälper (t.ex. en dedikerad worker) utan att dela upp i många deploys.
Behandla aviseringar som en förstklassig funktion: in-app + e-post, med avvalsalternativ och tydlig trådning. En jobbkön (BullMQ, Sidekiq, Celery, etc.) låter dig skicka påminnelser pålitligt, återförsöka fel och undvika att sakta ner uppladdningar och godkännanden.
Planera tre miljöer från start:
Om du vill fördjupa dig i datadelen nästa steg, fortsätt med /blog/data-model-and-database-design.
En ren datamodell är vad som håller din kampanjapp enkel även när den växer. Målet är att göra vanliga skärmar—kampanjlistor, asset-köer, godkännandesidor—snabba och förutsägbara, samtidigt som du fångar historiken du behöver senare.
Börja med en liten uppsättning tabeller som matchar hur byråer faktiskt arbetar:
Behåll ID:n konsekventa (UUIDs eller numeriska—båda funkar). Viktigt är att varje barnpost (clients, campaigns, assets) bär en organization_id så att du kan upprätthålla datainsolation.
Statusar förklarar inte allt. Lägg till tabeller som:
Detta gör audit trails och ansvar tydliga utan att blåsa upp dina kärntabeller.
De flesta skärmar filtrerar efter client, status, och due date. Lägg till index som:
Överväg också ett sammansatt index för “vad behöver granskas nu”, t.ex. (organization_id, status, updated_at).
Behandla ditt schema som produktkod: använd migrationer för varje ändring. Seed några kampanjmallar (standardsteg, sample-statusar, standardgodkännandesteg) så att nya byråer kan komma igång snabbt och dina testmiljöer har realistisk data.
En klientgodkännandeapp lever eller dör på förtroende: kunder behöver enkel inloggning, och ditt team behöver trygghet att endast rätt personer ser rätt arbete. Börja med minsta set auth-funktioner som ändå känns byråredo, och bygg ut sedan.
Om dina användare mestadels är kunder som loggar in sporadiskt är e-post + lösenord oftast smidigast. För större organisationer (eller enterprise-kunder), överväg SSO (Google/Microsoft) så att de kan använda befintliga företagskonton. Du kan stödja båda senare—undvik att göra SSO obligatoriskt om din målgrupp inte förväntar sig det.
Inbjudningar bör vara snabba, roll-medvetna och förlåtande:
Ett bra mönster är en magic link för att sätta lösenord, så nya användare inte behöver komma ihåg något från början.
Använd säker sessionshantering (kortlivade access-tokens, roterande refresh-tokens, httpOnly-cookies där möjligt). Lägg till en standard password reset-flöde med expirerande, engångstokens och tydliga bekräftelsesidor.
Autentisering svarar på “vem är du?” Auktorisering svarar på “vad kan du göra?” Skydda varje endpoint med behörighetskontroller—särskilt för kampanjassets, kommentarer och godkännanden. Lita inte enbart på att dölja UI-element.
Behåll auditvänliga loggar (inloggningsförsök, inbjudan accepterad, rolländringar, misstänkt aktivitet), men undvik att lagra hemligheter. Logga identifierare, tidsstämplar, IP/enhetstips och utfall—aldrig råa lösenord, fullständigt filinnehåll eller privata kundanteckningar.
Aviseringar är där kampanjappar antingen känns hjälpsamma—eller överväldigande. Målet är enkelt: håll arbetet i rörelse utan att varje kommentar blir en inkorgsbrand.
Börja med ett litet, högsignal-set triggers och håll dem konsekventa över e-post och in-app:
Gör varje avisering tydlig kring “vad” och nästa åtgärd med en direkt väg till rätt vy (t.ex. asset review-sidan eller klientinboxen).
Olika roller vill ha olika detaljnivå. Ge kontroll på användarnivå:
Använd smarta standardinställningar: kunder vill vanligtvis ha färre mail än interna team och bryr sig oftast bara om objekt som väntar på deras beslut.
Batcha liknande uppdateringar (t.ex. “3 nya kommentarer på Homepage Banner”) istället för ett mail per kommentar. Lägg in skydd:
En dedikerad Approval Inbox-sida minskar fram och tillbaka genom att visa endast vad klienten behöver göra nu: objekt “Waiting for you”, förfallodatum och en ett-klicksväg till rätt granskningsvy. Håll den ren och tillgänglig, och länka till den från varje granskningsmejl (t.ex. /approvals).
E-post är inte garanterat. Spara leveransstatus (sent, bounced, failed) och återförsök intelligent. Om ett mail misslyckas, visa det för admins i en aktivitetsvy och fall tillbaka till in-app-notiser så att arbetsflödet inte stannar tyst.
När kunder godkänner kreativt tar de inte bara ett klick—de tar ansvar för ett beslut. Din app bör göra den beslutshistoriken enkel att hitta, lätt att förstå och svår att bestrida i efterhand.
Implementera ett aktivitetsflöde på två nivåer:
Håll poster läsbara för icke-tekniska användare med ett konsekvent format: Vem gjorde vad, när och var. Exempel: “Jordan (Agency) laddade upp Homepage Hero v3 — 12 dec, 14:14” och “Sam (Client) godkände Homepage Hero v3 — 13 dec, 09:03.”
För ansvarstagande, lagra ett audit-spår för:
En praktisk regel: om en händelse påverkar leverabler, timing eller kundsign-off, hör den hemma i audit-trailen.
Audit-händelser bör i allmänhet vara immutabla. Om något behöver korrigeras, spela in en ny händelse (t.ex. “Approval re-opened by Agency”) istället för att skriva om historiken. Tillåt redigeringar för displayfält (som ett stavfel i asset-titel) men logga att en ändring skett.
Stöd export av en enkel sammanfattning (PDF eller CSV) för överlämning: slutgiltiga godkända versioner, godkännandetidsstämplar, nyckelfeedback och länkar till assets. Detta är särskilt användbart vid projektavslut eller när en kund byter team.
Görs väl, minskar detta förvirring, skyddar båda parter och gör din kampanjhanteringsprogramvara trovärdig—inte komplicerad.
Rapportering och integrationer kan lätt blåsa upp omfattningen av en kampanjgodkännandeapp. Tricket är att leverera minsta nyttiga set som hjälper team att köra arbete dagligen, och sedan expandera baserat på verklig användning.
Börja med en enkel rapportvy (eller widgets) som stödjer veckovis statuskontroll och daglig triage:
Lägg sedan till lätta hälsindikatorer för kampanjer som är lätta att förstå:
De behöver inte perfekt prognos—bara tydliga signaler och konsekventa regler.
Integrationer ska minska manuella uppföljningar, inte skapa nya felkällor. Prioritera efter användarnas dagliga vanor:
Även om du inte släpper ett publikt API direkt, definiera en tydlig förlängningsstrategi:
Phase 1: kärndashboards + väntande/försenade listor.
Phase 2: hälsoindikatorer + cykeltidstrender.
Phase 3: 1–2 högeffekt-integrationer (vanligen e-post + Slack).
Phase 4: webhooks och ett partnerklart API.
Om du överväger att paketera nivåer för rapportering och integrationer, håll det enkelt och transparent (se /pricing). Om du vill en snabbare väg till en MVP kan Koder.ai också vara användbart här: du kan iterera godkännandearbetsflödet i “planning mode”, distribuera en hostad build för feedback och rulla tillbaka via snapshots när du förfinar krav.
För djupare arbetsflödesmönster kan du även länka relaterad vägledning från /blog.
Börja med att definiera det grundläggande problemet: godkännanden och feedback sprids över e-post/chat/filer. Ditt v1 bör centralisera briefar, assets, feedback och sign-off så att alla intressenter snabbt kan svara:
Använd mätbara resultat som godkännande-omloppstid och antal revisionscykler för att hålla omfattningen realistisk.
Designa för fyra vanliga grupper:
Om du optimerar endast för interna användare kommer kundens adoption (och godkännandets hastighet) ofta att lida.
Välj ett litet set framgångsmått kopplade till verkliga friktioner i arbetsflödet:
Mät dessa tidigt så du kan validera förbättringar efter lansering av v1.
Ett praktiskt v1 innehåller:
Skjut upp avancerad rapportering, djupa integrationer, automationsregler och anpassade godkännandestigar tills du ser konsekvent användning.
Modellera arbetsflödet med några kärnobjekt:
Definiera sedan en godkännande-livscykel (t.ex. Draft → Internal review → Client review → Approved) där varje tillstånd har en operativ betydelse (vem kan flytta det, vad måste vara sant, vad händer härnäst).
Knyt alltid feedback till en asset-version för att undvika tvister om vilken fil som granskats. Bra alternativ inkluderar:
Struktur minskar omarbete genom att göra feedback handlingsbar och ansvarig.
Håll navigeringen konsekvent kring en enkel hierarki: Client → Campaign → Deliverables (assets). Viktiga “dagliga” skärmar är:
Lägg till filter som matchar verkliga frågor: klient, förfallodatum, status, ansvarig.
Börja enkelt med de roller som de flesta byråer behöver:
Definiera sedan behörigheter per objekt (campaign, asset, comment, approval) som view/comment/upload/approve/edit/delete. Använd “least privilege” och kontrollera rättigheter i backend—inte bara genom att dölja UI.
Behandla varje uppladdning som en ny, immutabel version (v1, v2, v3…). Skriv inte över filer på plats.
Spåra godkännande-metadata:
Vanligtvis låser du den godkända versionen men tillåter en ny version att skapas (vilket återställer status till In Review) när ändringar behövs.
En enkel arkitektur är:
För v1 är en modulär monolit med en jobbarprocess oftast enklare att leverera och drifta än många separata tjänster.