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

2. 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

3. 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?

4. 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

5. 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

6. 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 for dev

7. 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

8. 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”

9. 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

10. 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

11. 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

12. Contact information:
Simon Anstey