Kundevendte workflows bliver vanskelige, når teamet planlægger skærmbilleder, før det er enige om, hvem der må gøre hvad, hvilket system der ejer hver beslutning, og hvordan en ændring understøttes efter lanceringen. En nyttig plan følger kundens eller partnerens forløb gennem adgang, gendannelse af konto, formularer, filer, beskeder, dashboards, statusvisninger, betaling, abonnementer og overdragelse. Denne guide hjælper købere med at organisere disse spørgsmål før de vælger et omfang.
Hvad det er
Et kundevendt workflow kan strække sig over en portal, en webtjeneste, en mobiloplevelse, backend, API, betalingsudbyder, supportproces og et administrativt team. Planlægningen bør udpege brugerroller og adgangsgrænser; autentificering og gendannelse; formularer, filer, beskeder, dashboards og status; forløb for betaling, abonnement, faktura, refusion, opsigelse og rettigheder; dataejerskab og opbevaring; tredjepartsintegrationer; og driftsansvar. Den bør også afgøre, om mobil eller web er det rette, om den eksisterende backend og de eksisterende API'er er klar, og hvem der skal eje logning, support, ændringer og overdragelse. Sikkerhedsgennemgang og softwareleverance kan være separate omfang.
Hvem er det for?
Denne guide hjælper teams, der planlægger:
- En kunde- eller partnerportal, et modtagelsesworkflow, et dashboard, et betalingsforløb, et skift fra web til mobil eller en applikationslancering
- Rollebaseret adgang, gendannelse, filer, statusoplysninger, support og administrative ansvarsområder
- En produktændring, der involverer eksisterende backends, API'er, tredjepartsudbydere, faktureringstilstande eller kundedata
- En klarere grænse mellem discovery, design, leverance, hærdning, gennemgang og senere driftsejerskab
Hvad det hjælper med at afklare
Planlægningsspørgsmålene hjælper med at afdække:
- Om brugere, roller, adgangsregler, gendannelse af konti, dataejerskab og opbevaring er forstået, før leverancen begynder
- Hvilke formularer, filer, beskeder, dashboards, statusvisninger, betalingstilstande og beslutninger om rettigheder der krydser systemgrænser
- Om integrationer, backend/API'er, mobilleverance, lanceringsfase, logning, support og ejerskab af ændringer er klar til et afgrænset næste skridt
- Om teamet har brug for en portalsprint, en betalingsgennemgang, et skift fra web til mobil, en gennemgang af lanceringsparathed, hærdning af website eller tidligere discovery-/blueprint-arbejde
Hvad er inkluderet
- En tjekliste for købere, der dækker forløb, roller, adgang, autentificering, gendannelse, formularer, filer, beskeder, dashboards, status, betalinger, abonnementer, fakturaer, refusioner, opsigelser, rettigheder, data og integrationer
- Planlægningsspørgsmål om administrativt ejerskab, parathed i backend/API, mobil over for web, lanceringsfase, logning, support, ændringsstyring og overdragelse
- En sammenligning af, hvornår Secure Client Portal Sprint, Subscription & Payment Infrastructure Security, Secure Web-to-Mobile Launch, App Launch Readiness og Website Performance & Security Hardening kan være relevante
- En påmindelse om, at uklare workflows, roller, integrationer eller ejerskab kan kræve discovery- eller blueprint-arbejde før leverancen
Hvad er ikke inkluderet?
- Løfter om sikkerhed, regulatorisk egnethed, godkendte betalinger, forebyggelse af svindel, omsætning, godkendelse i app-butikker, vellykket lancering, oppetid, ydeevne eller uafbrudt drift
- En påstand om, at en portalsprint er en fuld SaaS-platform, at en betalingsgennemgang er PCI-certificering eller svindeldrift, eller at mobilleverance automatisk gør et produkt klar til lancering
- En antydning af, at hærdning erstatter applikationsdesign, belastningstest, hændelseshåndtering eller løbende drift
- En antagelse om, at softwareleverance, sikkerhedsgennemgang, godkendelse fra udbydere og løbende ejerskab er ét automatisk omfang
Hvornår du skal vælge det
Brug denne guide, før en kundevendt ændring bliver til en liste over usammenhængende funktioner. Den er nyttig, når et team skal beslutte, om det vil bygge en portal, ændre adgang, indføre abonnementer, udvide en webtjeneste til mobil, forberede en applikationslancering eller forbedre et website. Hvis det grundlæggende workflow, ejerskabet, integrationerne eller brugerrollerne fortsat er uklare, er discovery eller arbejde med et produktblueprint som regel mere værdifuldt end tidlig implementering. En afgrænset gennemgang kan derefter følge, når et konkret sikkerheds- eller driftsspørgsmål er klar.
Vores tilgang
Kortlæg forløbet, før leveringsmetoden vælges. Start med brugeren, brugerens rolle, adgangsbeslutningen, de data, brugeren leverer eller ser, det system, der ejer den næste tilstand, og det team, der har ansvaret, når noget ændres. Følg betalings- og rettighedstilstande lige så omhyggeligt som skærmbillederne. Udpeg derefter afhængigheder til udbydere og backend, behov for support og logning, mobile begrænsninger, ejerskab af udgivelser og krav til overdragelse. Det afslører, om den næste beslutning handler om levering af en portal, betalingslogik, arbejde fra web til mobil, lanceringsparathed, hærdning af website eller tidligere discovery. Det forhindrer også, at en afgrænset tjeneste forveksles med et ubegrænset ansvar for produkt, drift eller compliance. Et skriftligt kort over workflowet kan også registrere de normale og de afvigende forløb: en ny bruger, en mislykket betaling, en opsigelse, en mistet konto, en manglende fil, et nedbrud hos en leverandør eller en supporthenvendelse. Det giver produkt-, drifts-, udviklings- og supportteams et fælles sted at udpege ejerskab, før en kunde bliver berørt. Den klarhed kan mindske glidning i omfanget i senere leverancearbejde. Efterhånden som planlægningen udvikler sig, så vend tilbage til kortet, hver gang en udbyder, betalingsmodel, rolle, adgangsregel, API, udgivelseskanal eller supportproces ændres. Et workflow, der så enkelt ud på et diagram, kan have vigtige undtagelser i produktion. At registrere disse undtagelser gør det lettere at beslutte, om det næste omfang er design, leverance, gennemgang, hærdning, test eller driftsmæssig forberedelse. Det hjælper også en køber med at bede leverandører om den rette dokumentation, før en beslutning træffes. Brug endelig kortet til at beslutte, hvad der skal måles efter leverancen, og hvem der handler på et fund, en mislykket betaling, et supportsignal eller en ændringsanmodning. En overdragelse står stærkere, når den navngiver en ejer, et gennemgangspunkt og en aftalt grænse i stedet for blot at opliste funktioner.
Ofte stillede spørgsmål
Relaterede artikler
Start
Har I brug for at gøre et kundevendt workflow til en klarere beslutningsgrænse?
Beskriv workflowet, brugerne, systemerne, integrationerne og den beslutning, der skal afklares. Vi kan hjælpe med at udpege et forholdsmæssigt næste omfang.
Anmod om en samtale om planlægning af workflows