x
New members: get your first week of STAFFONO.AI "Starter" plan for free! Unlock discount now!
Արտադրանքի թարմացումները որպես diff-վերլուծություն. ինչպես բացատրել փոփոխությունները և չկորցնել օգտատերերին

Արտադրանքի թարմացումները որպես diff-վերլուծություն. ինչպես բացատրել փոփոխությունները և չկորցնել օգտատերերին

Արտադրանքի թարմացումների մեծ մասը ձախողվում է, քանի որ ասում է ինչ է թողարկվել, բայց չի ցույց տալիս ինչ է իրականում փոխվել օգտատերի համար։ Այս հոդվածում կսովորեք գրել թարմացումներ այնպես, կարծես diff-վերլուծություն է, պարզ ձևով նկարագրելով նախկին և նոր վարքագիծը և բացատրելով փոփոխության պատճառը։

Արտադրանքի թարմացումները պարզապես հայտարարություններ չեն։ Դրանք թարգմանություն են այն բանի միջև, ինչ ձեր թիմը ստեղծել է, և այն բանի, ինչ ձեր հաճախորդները վաղը պետք է անեն այլ կերպ։ Երբ թարմացումները մշուշոտ են, օգտատերը զգում է դիմադրություն. ինչ-որ բան տեղափոխվել է, ինչ-որ բան այլ կերպ է աշխատում, ինչ-որ բան «կարծես դանդաղել է», և արդյունքում աճում են հարցումները աջակցությանը, նվազում է ընդունումը, և խաթարվում է վստահությունը։

Գործնական մոտեցում է դիտարկել յուրաքանչյուր թարմացում որպես diff-վերլուծություն։ Ծրագրավորման մեջ diff-ը ցույց է տալիս, թե կոնկրետ ինչ է փոխվել. ինչն է ավելացվել, հեռացվել կամ փոփոխվել։ Օգտատերերին նույն հստակությունն է պետք, պարզապես արտադրանքի լեզվով։ «Վահանակը բարելավվել է» փոխարեն օգտակար է ասել. «Ֆիլտրը հիմա լռելյայն դրված է վերջին 30 օրերի վրա, ոչ թե 7, որպեսզի հաշվետվությունները համընկնեն ձեր հաշիվների շրջանի հետ»։ Սա է տարբերությունը ինֆորմացիայի և հասկացողության միջև։

Ինչու «ինչն է փոխվելը» բավարար չէ

Շատ թողարկման նշումներ թվարկում են ֆունկցիաները, բայց հաճախորդները փոփոխությունը գնահատում են արդյունքների և սովորությունների միջոցով։ Նրանք մտածում են. արդյո՞ք իմ աշխատանքային ընթացքը կխաթարվի, արդյո՞ք արդյունքները կփոխվեն, արդյո՞ք պետք է թիմին վերապատրաստեմ։ Եթե դուք չեք պատասխանում այս հարցերին, թարմացումը դառնում է ֆոնային աղմուկ, կամ վատագույն դեպքում անակնկալ։

Լավ թարմացումը կապում է չորս շերտ.

  • Տեսանելի փոփոխություն՝ ինչն է աչքի ընկնելու (կոճակներ, հոսքեր, լռելյայններ, թույլտվություններ)։
  • Վարքագծային փոփոխություն՝ ինչն է հիմա հնարավոր, արգելված, արագ, անվտանգ կամ կանխատեսելի։
  • Պատճառ՝ ինչ խնդիրն է բերել փոփոխությանը (հետադարձ կապ, կայունություն, համապատասխանություն, կատարողականություն)։
  • Գործողություն՝ ինչ պետք է անի օգտատերը հաջորդը (փորձել, տեղափոխվել, միացնել, սովորել կամ անտեսել)։

Եթե շերտերից մեկը բացակայում է, օգտատերը ստիպված է ենթադրել։ Ենթադրությունը թանկ է և ստեղծում է անորոշություն։

Գրեք թարմացումները diff-ի նման. «Մինչև, Հետո, Որովհետև, Հաջորդը»

Կարող եք թարմացումները դարձնել զգալիորեն հստակ, եթե յուրաքանչյուր կարևոր փոփոխություն ներկայացնեք որպես փոքր diff։ Օգտագործեք այս կառուցվածքը շարունակաբար.

Մինչև

Նկարագրեք նախորդ վարքագիծը պարզ լեզվով։ Առանց մեղադրելու անցյալը, պարզապես ասեք ինչպես էր աշխատում։

Հետո

Նկարագրեք նոր վարքագիծը, ներառյալ UI-ի փոփոխությունները և հիմքում ընկած կանոնները (լռելյայններ, սահմանափակումներ, եզրային դեպքեր)։

Որովհետև

Բացատրեք պատճառը, ցանկալի է կապելով օգտատիրոջ նպատակի կամ չափելի խնդրի հետ (արագություն, ավելի քիչ սխալներ, ավելի լավ կոնվերսիա, ռիսկի նվազեցում)։

Հաջորդը

Տվեք մեկ հստակ առաջարկվող քայլ։ Եթե քայլ չի պահանջվում, դա էլ ասեք ուղիղ։

Այս մոտեցումը կանխում է «հայտարարության մշուշը» և հեշտացնում է, որ Customer Success-ը և վաճառքը նույն կերպ փոխանցեն հաղորդագրությունը։

Գործնական օրինակներ diff-ոճի թարմացումների

Ստորև օրինակներ են, որոնք ցույց են տալիս, թե նույն թարմացումը ինչպես կարող է շփոթեցնել կամ պարզաբանել։

Օրինակ 1. Նոր լռելյայն կարգավորում

Մշուշոտ. «Մենք բարելավեցինք ծանուցումների կարգավորումները ավելի լավ փորձի համար»։

Diff-ոճով.

  • Մինչև. Թիմի նոր անդամները ստանում էին բոլոր ծանուցումները, ներառյալ ցածր առաջնահերթության ազդանշանները։
  • Հետո. Նոր անդամները հիմա ստանում են միայն բարձր առաջնահերթության ծանուցումներ։ Ցածր առաջնահերթությանները կարելի է միացնել Settings-ում։
  • Որովհետև. Թիմերը նշեցին, որ մեկնարկային փուլում աղմուկը շատ է, և կարևոր ազդանշանները կորում են։
  • Հաջորդը. Եթե ձեզ պետք են ցածր առաջնահերթության ազդանշանները, միացրեք դրանք մեկ անգամ և կիրառեք ձեր դերային ձևանմուշի համար։

Օրինակ 2. Ֆունկցիայի անվան փոփոխություն և կոճակի տեղափոխում

Մշուշոտ. «Մենք վերադասավորեցինք նավիգացիան»։

Diff-ոճով.

  • Մինչև. «Leads»-ը գտնվում էր Sales բաժնում, իսկ «Import»-ը վերևի աջ անկյունում էր։
  • Հետո. «Leads»-ը հիմա կոչվում է «Prospects» և գտնվում է Pipeline բաժնում։ «Import»-ը տեղափոխվել է Prospects էջի գործիքաշար։
  • Որովհետև. Շատ թիմեր prospects-ը կառավարում են որպես pipeline-ի քայլ, իսկ հին տեղադրությունը setup-ի ժամանակ բերում էր բաց թողնված ներմուծումների։
  • Հաջորդը. Թարմացրեք ներքին onboarding նյութերը, որտեղ օգտագործվում է հին անվանումը։

Փոքր փոփոխություններն էլ են կոտրում սովորությունը, և diff-ոճը դա հարգում է։

Օրինակ 3. Կատարողականության բարելավում, որը պետք է ապացուցել

Մշուշոտ. «Մենք արագացրինք հավելվածը»։

Diff-ոճով.

  • Մինչև. Մեծ հաղորդագրությունների պատմությունները բջջային ցանցերում բեռնվում էին 6-ից 10 վայրկյան։
  • Հետո. Նույն պայմաններում բեռնվում են 1.5-ից 3 վայրկյան, շնորհիվ փուլային (incremental) բեռնման։
  • Որովհետև. Դանդաղ բեռնումը ստիպում էր գործակալներին կրկնել հարցերը և նվազեցնում էր պատասխանների արագությունը։
  • Հաջորդը. Գործողություն չի պահանջվում, բայց եթե դեռ դանդաղ է, ուղարկեք էկրանի ձայնագրություն աջակցությանը, որպեսզի տեսնենք ցանցային ուղին։

Եթե հայտարարում եք բարելավում, չափեք և ներկայացրեք թվերով։ Դա թերահավատությունը դարձնում է վստահություն։

Ինչը ներառել հայտարարության մեջ

Ոչ ամեն փոփոխություն է արժանի լայն հաղորդագրության։ Նպատակը ավելի շատ հրապարակելը չէ, այլ այն, ինչը փոխում է որոշումները։ Օգտագործեք այս ֆիլտրերը.

  • Արդյո՞ք փոխվում է աշխատանքային ընթացքը։ Եթե թիմը պետք է այլ կերպ սեղմի կամ անցնի քայլերով, դա պետք է հայտարարել։
  • Արդյո՞ք փոխվում են արդյունքները։ Լռելյայններ, հաշվարկներ, attribuition, դասակարգումներ պետք է բացատրել։
  • Արդյո՞ք փոխվում է ռիսկը։ Թույլտվություններ, անվտանգություն, համապատասխանություն, տվյալների պահպանման կանոններ պետք է լինեն հստակ։
  • Արդյո՞ք փոխվում են ակնկալիքները։ Սահմանափակումներ, պլաններ կամ դադարեցման ժամանակացույցներ պետք է հաղորդել վաղ և կրկնվող կերպով։

Փոքր բագերի շտկումները կարող են մնալ changelog-ում, բայց աշխատանքային և արդյունքային փոփոխությունները պահանջում են պատմություն և ուղղորդում։

«Ինչու»-ն դարձնել հավաստի առանց երկար գրելու

Օգտատերերին պետք չեն ներքին քննարկումները։ Պետք է կարճ և հավատալի պատճառ։ Սովորաբար «ինչու»-ն տեղավորվում է այս խմբերում.

  • Հաճախորդների հետադարձ կապ՝ «Դուք ասացիք, որ X-ը շփոթեցնող է, և մենք փոխեցինք Y-ը»։
  • Կայունություն՝ «Սա նվազեցնում է timeout-երը և sync-ի ձախողումները»։
  • Անվտանգություն և համապատասխանություն՝ «Սա կանխում է տվյալների պատահական արտահոսքը»։
  • Արագություն և մասշտաբավորում՝ «Սա պահպանում է կատարողականությունը, երբ ծավալը աճում է»։
  • Համահունչ փորձ՝ «Սա նույնացնում է վարքագիծը web-ի և mobile-ի միջև»։

Թարմացումները հասցրեք այնտեղ, որտեղ օգտատերը իրականում տեսնում է

Նույնիսկ կատարյալ հայտարարությունը ձախողվում է, եթե այն սխալ ալիքով է հասնում։ Շատ թիմեր հույս են դնում միայն մեկ վայրի վրա (բլոգ կամ changelog), բայց օգտատերերը աշխատում են տարբեր միջավայրերում։ Գործնական բաշխման խառնուրդը կարող է լինել հետևյալը.

  • Ներսում կարճ հուշումներ, հենց փոփոխության պահին։
  • Email այն մարդկանց համար, ովքեր հաստատում են գործընթացները և կազմակերպում ուսուցումը։
  • Մեսենջերներ արագ թիմերի համար, որոնք ապրում են չաթում։
  • Օգնության կենտրոն որոնելի և կայուն փաստաթղթերի համար։
  • Վաճառքի և հաջողության թիմերի enablement միատեսակ բացատրությունների համար։

Այստեղ ավտոմատացումը կարող է որոշիչ լինել «հրապարակեցինք» և «հաճախորդը հասկացավ» տարբերության մեջ։ Staffono.ai (https://staffono.ai) կարող է աշխատել որպես 24/7 AI աշխատակից WhatsApp-ում, Instagram-ում, Telegram-ում, Facebook Messenger-ում և web chat-ում, պատասխանելով «ինչ է փոխվել» հարցերին նույն diff-հստակությամբ։ Հաճախորդը չի սպասում աջակցությանը, այլ հարցնում է իր նախընտրած ալիքով և ստանում է միատեսակ պատասխան։

Թարմացումները վերածեք ինքնասպասարկվող աջակցության շերտի

Թարմացումն ուղարկելուց հետո սկսվում է իրական աշխատանքը. հարցեր, եզրային դեպքեր, շփոթություն, ներքին ուսուցում։ Լավ թիմերը նախօրոք պատրաստում են FAQ և օրինակներ։

Յուրաքանչյուր խոշոր թարմացման համար կազմեք «ազդեցության փաթեթ».

  • Լավագույն 5 հարցերը, որոնք օգտատերը կխնդրի, և կարճ պատասխաններ։
  • Մեկ սքրինշոթ կամ կարճ տեսանյութ նոր ուղու մասին։
  • Մեկ սցենար, որը հիշեցնում է իրական գործառույթը։
  • Մեկ troubleshooting հուշում ամենահավանական խնդրի համար։

Եթե օգտագործում եք Staffono.ai, կարող եք այս FAQ-ները տեղադրել ձեր մեսենջերային ավտոմատացված հոսքերում, որպեսզի AI աշխատակիցը անմիջապես լուծի կրկնվող հարցերը, բարդ դեպքերը ուղղորդի մարդու մոտ, և նաև հավաքի հետադարձ կապ այն մասին, թե ինչն է դեռ անհասկանալի։ Ժամանակի ընթացքում դուք կունենաք չափելի հաղորդակցություն. կտեսնեք ինչ են հարցնում, որտեղ են խրվում, և ինչ փաստաթուղթ է պետք բարելավել։

Չափեք արդյո՞ք թարմացումը հասել է նպատակին

Հրապարակումը վերջը չէ։ Պետք են ազդանշաններ, որ օգտատերը հասկացավ և կիրառեց փոփոխությունը։ Ընտրեք մի քանի մետրիկա ըստ թարմացման տեսակի.

  • Ընդունում՝ նոր ֆունկցիայի օգտագործման տոկոսը 7, 14, 30 օրում։
  • Վարքագծային տեղաշարժ՝ հին ուղու օգտագործման նվազում, նորի աճ։
  • Աջակցության բեռ՝ թարմացման հետ կապված դիմումներ և լուծման ժամանակ։
  • Որակ՝ սխալների տոկոս, drop-off, latency կամ ձախողված գործողություններ։
  • Տրամադրություն՝ կարճ հարց in-app, չաթում պատասխանների տրամադրության վերլուծություն, կամ մեկնաբանություններ, որոնք կապվում են փոփոխության հետ։

Քանի որ Staffono.ai-ն աջակցում է messaging-first շփումներին, այն կարող է օգնել նաև թարմացումից հետո արագ հավաքել կարծիք մեծ ծավալով։ Օրինակ, երբ օգտատերը ավարտում է նոր հոսքը, AI աշխատակիցը կարող է տալ մեկ կարճ հարց. «Նոր քայլը ժամանակ խնայե՞ց, այո թե ոչ» և պիտակավորել պատասխանները արտադրանքի թիմի համար։

Սխալներ, որոնցից պետք է խուսափել

  • Մարքեթինգային բառեր առանց կոնկրետության՝ «բարելավված», «օպտիմալացված», «լավացված» բառերը անիմաստ են առանց diff-ի։
  • Կոտրող փոփոխությունների թաքցնում՝ եթե կարող է խաթարել աշխատանքը, նշեք սկզբում և տվեք մեղմացման քայլեր։
  • Միայն happy path-ի նկարագրում՝ նշեք հիմնական եզրային դեպքերը, հատկապես թույլտվությունների և ինտեգրացիաների համար։
  • Շատ փոփոխություններ մեկ հրապարակման մեջ՝ խմբավորեք ըստ օգտատիրոջ աշխատանքային հոսքերի, ոչ թե ըստ ներքին թիմերի։
  • Օգնության հստակ կետ չկա՝ տվեք հարց տալու պարզ ճանապարհ, նույնիսկ եթե առաջինը ավտոմատ է։

Կաղապար, որը կարող եք կրկնակի օգտագործել

Հաջորդ հայտարարության համար օգտագործեք այս կառուցվածքը յուրաքանչյուր կարևոր փոփոխության համար.

  • Ամփոփում. մեկ նախադասություն արդյունքի մասին։
  • Մինչև. նախորդ վարքագիծը։
  • Հետո. նոր վարքագիծը։
  • Որովհետև. պատճառը, կապված նպատակի կամ չափելի խնդրի հետ։
  • Հաջորդը. մեկ առաջարկվող քայլ։
  • FAQ. 3-ից 5 կարճ հարց ու պատասխան։
  • Որտեղ օգնություն ստանալ. հղում, չաթ կամ ալիք։

Եթե սա ճիշտ եք անում, թարմացումները դառնում են կուտակվող ակտիվ. նվազեցնում են աջակցությունը, բարձրացնում են ընդունումը և սովորեցնում են հաճախորդներին, թե ինչպես եք մտածում։

Եթե ցանկանում եք, որ ձեր թարմացումները հասնեն այն նույն ալիքներին, որտեղ ձեր հաճախորդներն արդեն հաղորդակցվում են, և այդ հայտարարությունները վերածվեն անմիջապես օգտակար պատասխանների ցանկացած ժամի, Staffono.ai (https://staffono.ai) կարող է օգնել։ AI աշխատակիցներով, որոնք կառավարում են հաճախորդների խոսակցությունները հանրահայտ մեսենջերներում և web chat-ում, դուք կարող եք վստահությամբ թողարկել փոփոխություններ, պահել օգտատերերին տեղեկացված իրական ժամանակում և ազատել թիմի ուշադրությունը հաջորդ թողարկման համար։