Project Plan: Login Self-Help Page
Background and goal
Login problems are the single largest driver of tickets for the customer-support team at Northwind Software. In the last quarter, login-related requests (forgotten passwords, locked accounts, two-factor authentication failures) made up 22% of all ticket volume. Most of these tickets follow the same few patterns and are resolved by agents repeating the same instructions.
This project delivers a public self-help page that lets customers resolve the most common login problems without opening a ticket.
Goal: cut login-related tickets by half (from 22% to roughly 11% of total volume) within two months of full launch.
Scope
In scope
- Step-by-step help for password reset
- Guidance for locked accounts, including how long a lock lasts and how to unlock
- Troubleshooting for two-factor authentication problems (lost device, codes not arriving, backup codes)
- A short "still stuck?" path that points to the correct ticket form, pre-tagged as a login issue
- Basic page analytics (views, click-through to ticket form, exit points)
Out of scope
- Billing questions of any kind, including subscription changes or refunds
- Account deletion requests
- Changes to the login flow or authentication system itself
- Translations into languages other than English (to be considered after launch)
Milestones
| Milestone | Date | Owner |
|---|---|---|
| Kick-off and outline agreed | 6 October | Support lead |
| Content drafted and reviewed | 20 October | Writer |
| Page built in staging | 5 November | Front-end developer |
| Pilot live with 10% of help-centre traffic | 15 November | Front-end developer |
| Pilot review and go/no-go decision | 25 November | Support lead |
| Full launch | 1 December | Support lead |
| Results review (two months post-launch) | 1 February | Support lead |
Who does what
| Role | Person | Responsibilities |
|---|---|---|
| Support lead | Priya Mehta | Project owner; supplies ticket data and common customer wording; approves content; runs pilot review; reports results |
| Writer | Tom Alvarez | Drafts and edits all page content; sets the review cycle with the product team; maintains the content after launch |
| Front-end developer | Lena Okafor | Builds the page, sets up traffic split for the pilot, wires analytics, handles the full launch |
A weekly 30-minute check-in is held every Tuesday from kick-off until the results review.
Risks and how they are handled
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Content goes out of date with product changes (e.g., a redesigned login screen) | Medium | High | Writer joins the product team's fortnightly release notes meeting; page carries a "last reviewed" date; content review is scheduled every release and at least monthly |
| Pilot traffic (10%) too low to measure an effect | Medium | Medium | Developer checks pilot volume after five days; if page views are under 500, the split is raised to 25% and the pilot extended by one week |
| Customers use the page but still open tickets | Low | Medium | Ticket form is pre-tagged so these cases can be counted; feedback widget on the page captures where instructions fail |
| Developer availability clashes with other sprint work | Low | High | Build dates agreed with the engineering manager at kick-off; one week of slack built in before the pilot |
How success is measured
Primary measure
- Share of login-related tickets falls from 22% to 11% or less of total volume, measured over the two months after full launch (1 December to 1 February) and compared with the two months before launch.
Supporting measures
- Page views per week during pilot and after launch
- Deflection rate: proportion of page visitors who do not go on to open a login ticket within 24 hours (target: 70% or higher)
- Click-through to the ticket form from the page (target: under 20% of visitors)
- Average handling time on remaining login tickets, as a check that the easy cases are being deflected
- Customer feedback on the page ("Was this helpful?" thumbs up rate, target: 75% or higher)
The support lead reports these figures at the pilot review and again at the results review on 1 February. If the primary measure is not met, the team reviews ticket samples to identify which login problems are still reaching agents and updates the content accordingly.