Eliminating Support Incidents Public Eliminating Support Incidents Simon Anstey, SAP TCUK Conference, September 2016

Last Year … Customers: Don’t always know about the documentation or where to find it Don’t always understand how documentation is structured Result: They contact support directly Developers & support engineers: Aren’t always familiar with or aware of the documentation Reply directly to customers instead of referring them to the correct point in the documentation

Last Year Development & support managers: - Our teams spend ages solving consulting incidents Writers: - Why do I bother if no one is reading it? - How can we add more value to the product and show it to management?

No Wonder Our Customers Are Confused Different Content SAP Library – writer “User guides” – SME KBAs – support Notes – support, developers Published in Different Places Help Portal Support Portal SAP Service Marketplace By Different People Different goals, managers, locations, board areas Resulting In .. A large number of support incidents

What Did We Do? Introduce a more collaborative approach to documentation: Bring together all parties involved in creating documentation Get everyone to work on one set of deliverables Make sure everyone internally and customers know what documentation is available Tech writer drives/owns the topic but is not responsible for creating everything Strong focus on support as a way of measuring the results

Pilot Projects New development project Around 150 days’ development Projected incidents after release: 50–100 Actual incidents: 2 Additional time investment: 6 hours all told Time saving: - 5–10 days for support - 2.5–5 days for scrum team Improvement of an existing development No. incidents per quarter: 55 After improvement: 0 Additional time investment was 8 days (4 days for support, 3 for writer, 1 for dev) Time saving: - 5 days for support - 2.5 for dev

Benefits & Positive Effects (Presumably) happier customers - In one case improved documentation was used to help prevent an escalation Significant and demonstrable time savings for support and developers Improved documentation that adds more value More visibility and job satisfaction for the tech writer All teams have kept to the working model We have set up a new project to cover an additional dozen topics

Tips for Making a Go of It: Project Initiation Get management buy-in – understand their motivation, e.g. zero incidents … arouse their interest Find out which writers or POs might be interested Look for new projects with a high projected incident count (large customer base, complex etc.) Look for writers who can “take charge”

More Tips: Project Kick-Off Writer takes over Kick-off meeting to discuss - Business goals of project - Customer base - Issues - Customer’s information needs - Deliverables - Roll-out - Who does what Set up an introductory meeting to explain the project idea, goals, working model Invite everyone in the extended scrum team Step back

Write the Documentation and Roll It Out as a Team Roll-out to customers - Webinars, customer forums - Video showing how to find documentation Writing the documentation Cross-references Mutual review: - Writer: structure, content, language - Support: content and scope - SMEs and PO: final review Internal roll-out Closing meeting with extended scrum team to show documentation Boilerplate text for re-use in communications with customers

Measure the Results & the Effort, Talk About It Follow Up Write report Present to management Set up new projects Review Meeting E.g. three months after close of peak incident time Review number of incidents and time savings

Contact information: Simon Anstey simon.anstey@sap.com