Der technische Support ertrinkt in verstopftem Netzwerkverkehr, einem Meer aus konvergierenden Technologien, Daten und Medien, die um Systemressourcen konkurrieren, und einzigartigen Konfigurationslandschaften f\u00fcr jeden Kunden. Am Ende der Wertsch\u00f6pfungskette positioniert, hat der technische Support kaum Mitspracherecht bei dem, was verkauft wird und wie es konzipiert und implementiert wird. <\/p>\n
Incident-Management und Fehlerbehebungsaktivit\u00e4ten k\u00f6nnen zu einem Schuldzuweisungsspiel nach dem Motto \u201eihr Fehler, nicht unserer\u201c, zu pers\u00f6nlichen Vermutungen oder zu Problem-Eskalationen durch erz\u00fcrnte Kunden werden. Die Probleml\u00f6sung wird zu einer Wahrscheinlichkeit \u2013 nicht zu einer Gewissheit. <\/p>\n
Durch den Einsatz zunehmend vernetzter und dennoch unterschiedlicher Technologien erwarten Kunden, dass ihr Gesch\u00e4ft trotz der Komplexit\u00e4t ihrer IT-Infrastruktur homogen unterst\u00fctzt wird. Organisationen, welche die Realit\u00e4t der komplexen, vernetzten IT-Umgebungen ihrer Kunden ignorieren, gehen ein Risiko ein \u2013 ebenso wie jene, die glauben, sie k\u00f6nnten diese Komplexit\u00e4t auslagern. <\/p>\n
Ein gemeinsames Thema, das sich durch unsere gesamte Kundenlandschaft zieht, ist, dass die technische Supportfunktion am Limit lebt. K\u00f6nnen sie die Kontrolle behalten? Wir glauben ja. <\/p>\n
Dieser Artikel er\u00f6rtert die Schw\u00e4chen von Supportfunktionen aus der Perspektive gesch\u00e4ftskritischer Supportfunktionen und stellt einen skalierbaren L\u00f6sungsprozess vor, der auf jedes Produkt, jede Plattform und jede Technologie angewendet werden kann.<\/p>\n
Die gute Nachricht ist, dass Manager und Entscheidungstr\u00e4ger innerhalb der Kundensupportfunktion mittlerweile erkennen, dass die Supportwelt immer komplexer wird. Die schlechte Nachricht ist, dass der Erfolg von Verbesserungsinitiativen nur sporadisch eintritt. Selbst in den besten Organisationen stagniert der Erfolg von Initiativen schnell, und die Investitionsrendite bleibt hinter den urspr\u00fcnglichen Versprechen zur\u00fcck. <\/p>\n
Hier ist das, was bisher nicht gut funktioniert hat:<\/p>\n
Ironischerweise folgen diese scheinbar \u201erichtigen Schritte\u201c einer logischen Abfolge, die Organisationen in eine Endlosschleife aus ineffektiven Reformen und neuen Initiativen treibt, die Ressourcen verbrauchen und Kunden frustrieren.<\/p>\n
1. Technische Schulungen sind f\u00fcr die effektive Steuerung des Supportprozesses von entscheidender Bedeutung. In der Regel machen Schulungen 5\u20136 % des Budgets eines Support-Centers aus, und die Mitarbeiter verbringen durchschnittlich etwa drei Arbeitswochen pro Jahr mit der Kompetenzentwicklung. Die meisten Schulungen finden w\u00e4hrend der Einarbeitung neuer Mitarbeiter und bei der Einf\u00fchrung neuer Produkte statt. Trotz bester Absichten greifen Schulungen aufgrund der Kapazit\u00e4tsgrenzen des menschlichen Lernens zu kurz. Ein Support-Mitarbeiter kann f\u00fcr zwei, drei oder vielleicht vier Produkte zertifiziert sein, aber diese Zertifizierung bringt noch keine Expertise mit sich. Kein technisches Schulungshandbuch kann die Konfigurationskomplexit\u00e4t und Dynamik der einzigartigen IT-Infrastruktur eines Kunden simulieren, und der Analyst ist gezwungen zu improvisieren. Dies f\u00fchrt zu inkonsistentem Support, dem Hauptgrund f\u00fcr sinkende Kundenzufriedenheitswerte. <\/p>\n
Mitarbeiter im technischen Support schwimmen fachm\u00e4nnisch in bekannten Gew\u00e4ssern, aber wenn sie Situationen ausgesetzt sind, in denen es ihnen an Wissen und Erfahrung mangelt, gehen sie unter. Fragen Sie einen beliebigen Support-Analysten \u2013 das gr\u00f6\u00dfte Berufsrisiko, dem Analysten heute gegen\u00fcberstehen, ist die fast sichere Gewissheit, dass das n\u00e4chste Ticket au\u00dferhalb ihrer Expertise liegen wird. <\/p>\n
Kompetenzbasiertes Routing (Skills-based Routing) ist eher ein Pflaster als eine dauerhafte L\u00f6sung f\u00fcr Zuweisungs- und Planungsherausforderungen. Die Routing-Regel weist Probleme zu einem Produkt normalerweise einem definierten Experten zu. ACDs (Automatic Call Distributors) werden installiert, um diesen Prozess zu erleichtern. Dies f\u00fchrt oft zu Situationen von \u00dcberlastung oder Leerlauf, in denen \u201egute\u201c Ressourcen ausbrennen, w\u00e4hrend \u201eandere\u201c Ressourcen unterausgelastet sind. Die Nutzung der Historie zur Planung der richtigen Produktspezialisten in Erwartung des n\u00e4chsten gesch\u00e4ftskritischen Support-Tickets mangelt an Effizienz und Effektivit\u00e4t. Trotz der Bem\u00fchungen, Technologien und Systeme bereitzustellen, sinkt der R\u00fcckstau an F\u00e4llen nie. Und wenn komplexe Probleme auftreten, versagt das Routing. <\/p>\n
2. Produktbasiertes Scripting wird vom Management eingesetzt, um den Leistungsdurchschnitt zu verbessern, und ist das Grundprinzip des Outsourcing-Modells. Alles, was man tun muss, um den Glauben des Managements an Skripte zu ersch\u00fcttern, ist, sich einen skriptbasierten Versuch zur L\u00f6sung eines gesch\u00e4ftskritischen Tickets anzuh\u00f6ren. <\/p>\n
Mitarbeiter an vorderster Front haben kein Problem damit, dem Skript zu folgen, oft bis zum Exzess. Scripting funktioniert f\u00fcr bekannte oder routinem\u00e4\u00dfige Situationen. Sobald die Situation jedoch leicht vom Skript abweicht oder der Kunde ein komplexes Problem anspricht, bricht das Skript zusammen. Der Kunde, der das Scripting und die mangelnde Logik bemerkt, geht davon aus, dass das Problem au\u00dferhalb der Kapazit\u00e4ten des Analysten liegt, und stellt die Glaubw\u00fcrdigkeit des Helpdesks infrage. Das Vertrauen ist dahin. <\/p>\n
Angesichts der wachsenden Komplexit\u00e4t des Supports ist ein Skript bereits am Tag seiner Erstellung veraltet, und sein Nutzen nimmt von da an stetig ab.<\/p>\n
Eine Analyse der Garantiekosten verdeutlicht ebenfalls das Scheitern von Scripting. Die Verwendung von Skripten zeigt eine nahezu perfekte Korrelation zum Volumen der versandten Ersatzteile und der geplanten Vor-Ort-Eins\u00e4tze. Anrufe werden auf Helpdesk-Ebene abgeschlossen, was f\u00fcr das Unternehmen mit hohen Kosten verbunden ist, und in vielen F\u00e4llen ist die Diagnose falsch. <\/p>\n
3. Wissensmanagement-Tools (KM-Tools) bieten eine L\u00f6sung, wenn Schulungen und Wissensaustausch nicht funktionieren und die Servicekosten eskalieren. Das Management ger\u00e4t unter Druck, das menschliche Element zu minimieren und KM-Tools zu installieren. Servicetechnologie macht 6\u20137 % der Budgets von Support-Centern aus, und fast 70 % der Organisationen f\u00fchren jedes Jahr KM-Projekte durch. Wissensmanagement erm\u00f6glicht selten Quantenspr\u00fcnge bei der Kundenzufriedenheit oder eine Reduzierung der mittleren L\u00f6sungszeit (MTTR). Im Gegenteil: Mehr Technologie legt Support-Fehler offen und beschleunigt sie. <\/p>\n
Betrachten Sie ein typisches Szenario: Analyst A l\u00f6st ein Problem und tr\u00e4gt die L\u00f6sung in die KM-L\u00f6sungsdatenbank ein. Analyst B st\u00f6\u00dft auf ein \u00e4hnliches Problem (vielleicht passend, vielleicht auch nicht), nutzt aber weder die L\u00f6sung von A noch das Kernproblem, weil B den eigenen Weg der Fehlerbehebung f\u00fcr den richtigen h\u00e4lt. Also f\u00fcgt B eine eigene Version der L\u00f6sung hinzu. Oder Analyst B glaubt, dass beide Probleme identisch sind, findet die L\u00f6sung von A und sendet denselben Patch, obwohl es nicht der richtige ist, was folglich zu weiteren Problemen f\u00fcr den Kunden f\u00fchrt. <\/p>\n
KM-Tools sind, ungeachtet ihrer Ausgereiftheit, wahrscheinlich die am meisten missbrauchten Technologien in Support-Organisationen.<\/p>\n
4. Durchschnittsbasierte Leistungskennzahlen verschleiern das Scheitern von Skripten bei der Verbesserung der Zufriedenheitswerte und von KM-Tools beim Schlie\u00dfen dieser L\u00fccken. Eine Organisation kann eine reasonably gute MTTR (Mean Time-to-Resolve) vorweisen, aber unter dieser Statistik verbergen sich die extremen Tickets. Dies sind die Probleme, die sich in die L\u00e4nge ziehen, Energie und Ressourcen verschlingen und die Kundenzufriedenheit sch\u00e4digen (Extremwerte, die in den durchschnittlichen Kundenzufriedenheitswerten untergehen). <\/p>\n
Durchschnittsbasiertes Reporting schafft einen Kreislauf, der die Einstellung \u201eerst flicken, sp\u00e4ter Probleme l\u00f6sen\u201c belohnt. Sobald das Ticket ge\u00f6ffnet ist, liegt kaum noch Gewicht auf Bewertung und Prozess \u2013 die Ziele bestehen darin, das SLA (Service Level Agreement) einzuhalten und die Dringlichkeit der Situation zu verringern, anstatt die Fehlerbehebung bis zum Abschluss durchzuf\u00fchren. Die Fallprotokolle werden zu endlosen E-Mail-Threads mit Anfragen nach Protokolldateien, die verschwenderische Leerlaufzeiten erzeugen, in denen nichts zur L\u00f6sung des Falls getan wird. <\/p>\n
Der Incident-Management-Prozess von ITIL hat gro\u00dfes Potenzial, aber die Standardisierung des Incident-Management-Prozesses auf Basis eines unzusammenh\u00e4ngenden Fehlerbehebungsprozesses wird wahrscheinlich keine nachhaltigen Ergebnisse liefern. Die langfristige L\u00f6sung f\u00fcr Helpdesk- und technische Supportfunktionen ist ein definierter Prozess, der unabh\u00e4ngig von Technologie, Plattform, Sprache oder Geografie ist. <\/p>\n
Bevor wir diesen Prozess etablieren, lade ich Sie ein, die Supportfunktion durch die Augen Ihrer Kunden zu betrachten.<\/p>\n
Untersuchungen zum Kundenfeedback in verschiedenen Branchen und Regionen zeigen, dass Kunden sieben Hauptprobleme mit dem Support haben.<\/p>\n
Diese sind:<\/p>\n
Alle Initiativen innerhalb der Kundenbetreuungsfunktion m\u00fcssen diese sieben Problembereiche jederzeit in den Mittelpunkt stellen. Diese Kundenanliegen sind die Plattform, auf der der gesch\u00e4ftskritische Supportprozess aufgebaut ist. <\/p>\n
Die Behauptung, bereits einen Fehlerbehebungsprozess zu haben, wird durch die Konsistenz des Supports gepr\u00fcft. Stellen Sie die L\u00f6sungszeiten nach Produkt und Support-Mitarbeiter grafisch dar. Die Normalkurve wird die Variabilit\u00e4t verdeutlichen. Die Variabilit\u00e4t zeigt auf, dass \u2013 falls tats\u00e4chlich ein Prozess existiert \u2013 dieser nicht befolgt wird. <\/p>\n
Oft glauben Analysten nicht an den vorhandenen Prozess und nutzen ihren eigenen Weg der Fehlerbehebung. Solche eigenm\u00e4chtigen Prozesse sind nicht nur unsichtbar, sondern brechen h\u00e4ufig zusammen, sobald etwas Au\u00dfergew\u00f6hnliches passiert. <\/p>\n
Viele Organisationen scheinen sich mit Mittelm\u00e4\u00dfigkeit abgefunden zu haben. Sie brauchen etwas grundlegend anderes, um den Kundensupport als gewinnbringendes Element ihrer Gesch\u00e4ftsstrategie zu etablieren. <\/p>\n
Eine branchenweite Umfrage zur Selbsteinsch\u00e4tzung der Leistung von Support-Centern zeigt, dass viele Organisationen sich offenbar mit Mittelm\u00e4\u00dfigkeit abgefunden haben. Es besteht eindeutig Raum und Bedarf f\u00fcr etwas grundlegend anderes, um den Kundensupport als gewinnbringendes Element ihrer Gesch\u00e4ftsstrategie zu etablieren. <\/p>\n
\u00dcberlegenes Wissen und Verst\u00e4ndnis von Kundenproblemen und deren L\u00f6sung ist durch einen rationalen Prozessansatz m\u00f6glich. Dies geschieht durch den Erwerb von F\u00e4higkeiten in strukturierten Fragetechniken, die Verbesserung der F\u00e4higkeit, diese F\u00e4higkeiten in Echtzeit einzusetzen, und den Aufbau von Kompetenz durch wiederholte Anwendung. <\/p>\n
Diese strukturierte Fragestellung wird integraler Bestandteil der Kundeninteraktion. Professionalit\u00e4t wird durch die Schaffung eines Leistungssystems erreicht, das die Nutzung rationaler Prozesse in jeder Supportfunktion f\u00f6rdert. Unabh\u00e4ngig von Plattform, Technologie und Supportsystem kann der rationale Prozessansatz skaliert werden, um die komplexesten Herausforderungen der Helpdesk- und Kundenbetreuungslandschaft zu bew\u00e4ltigen. <\/p>\n
Der Prozess baut auf vorhandenem Wissen und g\u00e4ngigen Praktiken auf, da er die pers\u00f6nliche und organisatorische Effektivit\u00e4t verbessert. Er unterst\u00fctzt und integriert alle guten organisatorischen Lernprozesse, Systeme und Kundenmanagementpraktiken, die bereits vorhanden sind. <\/p>\n
Ein rationaler Prozessansatz zur Fehlerbehebung gesch\u00e4ftskritischer Probleme beginnt mit der Bewertung (Appraisal), einer Einsch\u00e4tzung der Situation des Kunden. Die Bewertung nutzt Logik, um Daten zusammenzustellen und das Problem zu definieren. Darauf folgt die L\u00f6sung (Resolution), ein Prozess zur Identifizierung m\u00f6glicher Ursachen, deren Pr\u00fcfung gegen die Problemspezifikation sowie die Auswahl und Pr\u00fcfung der wahrscheinlichsten Ursache. <\/p>\n
Getrieben von der Dringlichkeit, die schnellstm\u00f6gliche L\u00f6sung zu finden und das Ticket zu schlie\u00dfen, ist die Bewertung oft das fehlende Puzzleteil in einer typischen Supportumgebung. Doch eine richtig durchgef\u00fchrte Bewertung kann die L\u00f6sung beschleunigen, indem sie diese h\u00e4ufigen Fallstricke verhindert: <\/p>\n
Bewertung ist kein fertiges Produkt: Sie ist der Grundstein f\u00fcr eine effektive Fehlerbehebung. Bewertung ist ein Dialog zwischen Kunden sowie Frontline- und Backline-Support. Es ist eine Zusammenarbeit, die den technischen Support von einer komplexen, oft undurchsichtigen Realit\u00e4t zu umsetzbaren Schritten f\u00fchrt. Wenn sie richtig gemacht wird, \u00fcberwindet die Bewertung die Verwirrung am Scheideweg zwischen adaptiven L\u00f6sungen und effektiver Behebung. <\/p>\n
Eine effektive Bewertung hilft dem Support-Personal, Probleme mit gezielten Fragen und Techniken zu durchdringen:<\/p>\n
Getrieben von der schnellstm\u00f6glichen L\u00f6sung ist es leicht, voreilig auf die Ursache zu schlie\u00dfen. Ein Prozessansatz zur L\u00f6sung kann die Fehlerbehebung beschleunigen, wenn Sie diese h\u00e4ufigen Fallstricke vermeiden: <\/p>\n
Wie steuert ein rationaler Prozess Eskalationen? Eskalationen treten normalerweise auf, wenn die Frontline an die Grenzen ihres Wissens und ihrer Erfahrung st\u00f6\u00dft. Durch einen rationalen Prozessansatz \u00fcbergibt die Frontline ein Ticket, das genau so strukturiert ist, wie die Backline es strukturiert h\u00e4tte. Dies reduziert repetitive Interaktionen mit Kunden und vermeidet Leerlaufzeiten. <\/p>\n
Mitarbeiter identifizieren die Grundursache durch diese logikgesteuerten Fragen und Techniken:<\/p>\n
Wenn Kunden erkennen, dass ihnen zugeh\u00f6rt wird und nicht nach Skript verfahren wird und dass der Analyst logische Fragen stellt, baut dies Vertrauen in den Analysten und die Organisation auf.<\/p>\n
Jederzeit kann jedes Mitglied des Helpdesks, nicht nur der Produktspezialist, einen Kundenanruf entgegennehmen und derselben Logik folgen, um signifikante Fortschritte in die richtige Richtung zu erzielen.<\/p>\n
Der Fehlerbehebungsprozess kann in vollem Umfang oder in einem informellen Schnellreaktionsmodus angewendet werden.<\/p>\n
Gesch\u00e4ftskritische Supportsituationen, die Hauptkandidaten f\u00fcr eine umfassende Anwendung sind, k\u00f6nnen sein:<\/p>\n
Je nach Branche und Produktreife fallen 5\u201310 % der Tickets in diese Kategorie. Diese Tickets verbrauchen jedoch 30\u201350 % der Ressourcen der Organisation. Die umfassende Nutzung des Prozesses kann einen gro\u00dfen Einfluss auf Zufriedenheits-, L\u00f6sungs-, Verl\u00e4ngerungs- und Kostenmetriken haben. <\/p>\n
Die \u00fcberwiegende Mehrheit der Helpdesk-Situationen ist normalerweise:<\/p>\n
In der Regel fallen 15\u201350 % der F\u00e4lle in diese Kategorie. Eine informelle Prozessanwendung kann zu erheblichen Verbesserungen bei den Zufriedenheitswerten, der Konsistenz und dem Aufbau von Glaubw\u00fcrdigkeit f\u00fchren. <\/p>\n
Ergebnisse<\/em><\/strong><\/p>\n Kepner-Tregoe bietet einen logischen Rahmen f\u00fcr die Fehlerbehebung. Durch Schulungen, Gesch\u00e4ftsprozessintegration und Verbesserung des Leistungssystems hat der KT-Prozess in Support-Umgebungen f\u00fcr Sun Microsystems, Dell, Cisco, EMC und andere hervorragende Ergebnisse geliefert. Repr\u00e4sentative Kennzahlen umfassen: <\/p>\n Stellen Sie sich vor, welche Verbesserungen dies f\u00fcr die Kundenzufriedenheit bringt.<\/p>\n Mehrere philosophische und strukturelle \u00c4nderungen m\u00fcssen erfolgen, um eine Best-Practice-Nutzung des Prozesses zu entwickeln.<\/p>\n Philosophisch gesehen brauchen wir einen Paradigmenwechsel: Der Helpdesk sollte aufh\u00f6ren zu behaupten, ein Produkt oder eine Anwendung zu unterst\u00fctzen. Beim Helpdesk geht es darum, das Gesch\u00e4ft des Kunden zu unterst\u00fctzen. Es geht darum, Fehler pr\u00e4zise zu beheben, w\u00e4hrend man den Kunden durch den Prozess f\u00fchrt und anschlie\u00dfend beweist, dass das Problem gel\u00f6st ist. <\/p>\n Um einen strukturellen Wandel zu realisieren, konzentrieren Sie sich darauf, die wenigen kritischen Bereiche zu identifizieren und zu definieren, die verbessert werden m\u00fcssen \u2013 nicht alles Erdenkliche. Ein potenzieller Ansatz k\u00f6nnte darin bestehen, sich auf eskalierte F\u00e4lle zu konzentrieren, deren L\u00f6sung l\u00e4nger dauert, oder auf F\u00e4lle, die aufgrund ihrer katastrophalen Dringlichkeit normalerweise schneller gel\u00f6st werden k\u00f6nnten, aber einen \u00fcberm\u00e4\u00dfigen Aufwand seitens der Organisation erfordern. Legen Sie spezifische Kennzahlen und Kausalfaktoren f\u00fcr diese Bereiche fest und bilden Sie dann Ihren aktuellen Prozess ab. Investieren Sie Zeit und Ressourcen in die Beseitigung von Leerstellen oder L\u00fccken im Prozess, w\u00e4hrend Sie kontinuierlich Schritte ohne oder mit geringem Mehrwert entfernen. Wenn der Fokus auf den wenigen kritischen Punkten liegt, erzielt die Kundensupportfunktion schnelle Ergebnisse und beginnt, dauerhaften Wert zu realisieren. <\/p>\n Das Endziel ist eine Reise \u00fcber drei Dimensionen:<\/p>\n Kompetenzentwicklung<\/strong> \u2013 Um sicherzustellen, dass die Mitglieder des Kundensupport-Teams \u00fcber die F\u00e4higkeiten und die Coaching-Unterst\u00fctzung verf\u00fcgen, die f\u00fcr den Erfolg erforderlich sind.<\/p>\n Prozessintegration<\/strong> \u2013 Um sicherzustellen, dass klare Verbindungen zwischen den erworbenen F\u00e4higkeiten und den Gesch\u00e4ftsprozessen bestehen.<\/p>\n Integration des Leistungssystems<\/strong> \u2013 Um sicherzustellen, dass das Arbeitsumfeld (Erwartungen, Kennzahlen, Tools\/Ressourcen, Konsequenzen und Feedback) der Nutzung der neuen F\u00e4higkeiten und des Prozesses f\u00f6rderlich ist.<\/p>\n Ein rationaler Prozess, der unabh\u00e4ngig von einem spezifischen Produkt oder einer Technologie ist, erm\u00f6glicht es der Kundenbetreuung, Produkte, Plattformen und Technologien \u00fcbergreifend zu bearbeiten. Er bietet einen soliden Rahmen f\u00fcr die Unterst\u00fctzung des Kundengesch\u00e4fts, indem er die wachsende Komplexit\u00e4t und den st\u00e4ndigen Wandel der technischen Supportumgebung bew\u00e4ltigt. <\/p>\n \u00a0<\/p>\n Kepner-Tregoe ist f\u00fchrend in der Probleml\u00f6sung. Seit \u00fcber sechs Jahrzehnten hat Kepner-Tregoe Tausenden von Organisationen weltweit geholfen, Millionen von Problemen durch effektivere Ursachenanalyse und bessere Entscheidungsf\u00e4higkeiten zu l\u00f6sen. Kepner-Tregoe arbeitet mit Organisationen zusammen, um Kosten deutlich zu senken und die operative Leistung zu verbessern \u2013 durch Trainings zur Probleml\u00f6sung, Technologie und Beratungsleistungen. <\/p>\n","protected":false},"excerpt":{"rendered":" Die Komplexit\u00e4t des technischen Supports bew\u00e4ltigen Mitarbeiter im technischen Support finden sich routinem\u00e4\u00dfig in den unbekannten Gew\u00e4ssern zunehmend komplexer und heterogener Anwendungen und Hardwareplattformen wieder. Das den Kunden gegen\u00fcber vermarktete Versprechen ist die Bequemlichkeit von \u201ewas auch immer, wann auch immer und wo auch immer\u201c; doch es wird kaum dar\u00fcber nachgedacht, wie wir dieses Versprechen […]<\/p>\n","protected":false},"author":8,"featured_media":38556,"template":"","white-paper-type":[],"class_list":["post-63763","white-paper","type-white-paper","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n\n
Bereit \u2013 Was muss sich \u00e4ndern?<\/h4>\n
Fazit \u2013 Es ist eine Reise<\/h4>\n
\u00dcber Kepner-Tregoe<\/h4>\n