Общ capability map
По-широкият поглед как priority workflow-ът се свързва с Content и Merchants.
След sync-а идва истинската работа: да решиш кои страници да влязат първи в backlog-а и към кого да отидат задачите.
Това е процесът, с който превръщаш суровите колони от export-а в работен план.
Не е достатъчно да видиш числата. Трябва да решиш коя страница е важна, какъв е проблемът и кой трябва да действа.
| Файл / изглед | За какво служи |
|---|---|
| Пълен export по страници | Когато ти трябва целият контекст на страницата и issue-ите. |
| Priority pages export | За първоначална подредба на URL-ите с реален потенциал и priority band. |
| Performance summary PDF | За кратък преглед към мениджмънт или developer екип при speed казуси. |
| Deep browser export | Когато трябва да покажеш TTFB/FCP/LCP и diagnostics screenshots по конкретни sample страници. |
| Export по issue код | За handoff към конкретен екип по конкретен проблем. |
Ако проблемът е content или snippet related, можеш да използваш Content услугата, да подадеш custom prompt и да тестваш подобрен текст върху ограничен набор от страници.
Ако проблемът е технически, export-ът, explanatory блоковете и при speed казуси performance diagnostics са по-подходящи за developer handoff. Важно е да не смесваш двата типа задачи в един неструктуриран списък.
При stakeholder разговори PDF summary често е по-полезен от суров CSV, а deep browser export-ът остава за работния екип.
Направи първи handoff с 10–20 URL-а и ги раздели по роли. Това е по-полезно от един огромен export, който никой не може да приоритизира.