No matter how good the search technology and how closely it meets user requirements without an appropriate level of investment in the search support team the chances of continuing to meet the requirements of the organization and the individual requirements of users are going to be close to zero. My main objective in writing this book was to get this message across as clearly as possible.
Implementing search should never be ‘a project’. The work of ensuring that users continue to have high levels of search satisfaction will never come to a close. Each week, and perhaps even most days, there will be something that needs attention. The role of the search support team is not just to be reactive but to anticipate when changes to the search application need to be made, or to identify a training requirement that will address an issue that is just starting to show up on the search logs and user satisfaction surveys.
The strange thing is that for other applications organizations seem more than ready to provide a high level of support staff. Research from Computer Economics Inc. in 2011 suggested that the median level of support for an Enterprise Resource Planning application is 75 users per member of the support team. Translate this into 20,000 users of a search application and the result would be a requirement for a support team of nearly 600 people! Research carried out by Findwise suggests that a median figure for an enterprise search team is probably 300 people!
It is not possible to state definitively how many people there should be in a search support team. Some of the factors that need to be taken into account are:
The level of support provided by the vendor, systems integrator or external development team
The extent to which search is a business-critical application and a delay of even a few hours in fixing a problem could have an impact on corporate reputation
The number of different business activities, each of which is likely to have its own technical language and use cases
The extent to which the search application has to cope with more than a single language
The global distribution of search users
The global distribution of indexed repositories
The level of local technical support
The extent to which IT Help Desks are able to provide support for search users
The volume of searches, which will have an impact on the scale of the search logs
The extent of federated searching, which tends to throw up more challenges for search support teams than almost any other aspect of search implementation
Not all members of the search team will be engaged full time on supporting users, but overall there are some well-defined roles and responsibilities that need to be covered.
The key roles that need to be filled in a search support team are the following:
This role is not an IT role but instead requires a very good understanding of how information is used in the business, with a particular emphasis on unstructured information. The Search Manager might usefully have a background in information science or business intelligence applications but the key success factor is that they understand the language of the business. Excellent project management skills are also essential as this is going to be a complex installation and any failure to deliver will be very visible to the majority of the workforce.
As well as managing the search team the Search Manager needs to maintain a close working relationship with the search vendor and the search integrator, not only so that problems that arise with the search software are quickly addressed but also to gather and assess the experience of these partners from other installations. Sadly it seems that many vendors are unwilling to bring their customers together to share experiences and good practice.
This is an IT role and the person concerned will be responsible for assessing server and network performance, crawling schedules, load balancing, back-up and disaster recovery. In a multi-national company this may require treading on the operations of national IT managers. Typically an ERP or CRM application is country or at most regional specific, but enterprise search will be global from the outset and requires 24/7 availability. This may require an investment in hardware from the centre which cannot be justified by a national IT operation.
As a result this can be a ‘management’ role as much as a technical role as the person concerned has to have the experience and the authority to ensure that things happen in operations over which they have no direct control. Just agreeing this can be a lengthy process of political negotiation, and needs to start right up front, and not when the software is about to be installed.
Another important responsibility of the Search Technology Manager is to manage information security, user authentication and user permissions. It is usually not until an enterprise search application is implemented that all sorts of ‘confidential’ information is found lurking on shared drives.
Finally this role should take responsibility for API management and documentation Effective enterprise search across multiple applications will require some complex APIs which have to be kept under review as the individual applications are upgraded or re-structured. The scope of this role also includes tracking the performance of document filters and connectors, both of which can be susceptible to even small changes in application configuration.
One of the critical success factors for enterprise search is the quality and regularity of the interpretation of search analytics. The volume of the search reports is very extensive. In one global consulting business around 500,000 searches were being carried out each month. One of the most important tasks for the Search Analytics Manager is to work through the searches which resulted in zero hits being found. If the assumption is made that only 0.1% of searches failed to find anything then this still represents a total of 500 searches a month, or around two each working day. Finding out why this search has failed may require some detective work, and certainly some feedback to the search user.
Good search needs good consistent metadata, and yet metadata management is not given the priority it needs in an enterprise search implementation. As has been highlighted earlier relevance ranking invariably places more weight on words and concepts in the title of the document.
If the title is missing nor is not well written then the relevance of that document may be decreased even if in fact the value to the user of the content of the document is high. The Information Specialist ideally needs to have a background in information science or in librarianship so that they have a fundamental training in metadata management and in the benefits and challenges of taxonomies.
A good taxonomy can be of considerable value in enhancing the search dialogue, but the development of taxonomies requires specialist skills, especially where a company is working in more than one language. Some search products (and Verity was a good example) offer customers support in the development of taxonomies, but it has to be realised that at present, and perhaps for some years to come, a totally computer-based approach to taxonomy development is not likely to be available. Of course some search vendors decry taxonomies and say that their product does not require such an artefact from the world of library science. That may or may not be the case, so the Information Specialist should have the skills to determine the truth in this statement in terms of the particular collections that the company wishes to make searchable.
Another responsibility of the Search Information Specialist should be to conduct some standard test queries on topics that emerge from the search logs as popular searches. A lot can be learned from these queries, and they are a good basis for developing some best bets for common search queries.
This person acts as the user-facing member of the team, undertaking training and usability testing, and providing feedback from surveys on the performance of the application. Although in theory search applications claim to need only minimal training the reality is that this is not the case, especially where federated searching is being carried out. Users may not fully appreciate the provenance of the various information repositories being searched and will need good guidance notes and suitable Help documentation on the search application.
Another important role for the User Support Manager is to develop and maintain good communications channels with users, perhaps using a section of the intranet, a wiki or a series of blog posts to keep everyone informed about the on-going development of the search application, highlight ‘tips and tricks’ and report back on the solutions that have been found to the inevitable range of problems that have been identified.
In summary this analysis indicates that there are five search team roles:
Search Manager
Search Technology Manager
Search Information Specialist
Search Analytics Manager
Search Support Manager
At the specification and selection stage not all of these are required full time. In principle it might be thought that there is no requirement for the Search Analytics Manager at this stage but given the importance of analytics they need to be involved in ensuring that the analytics requirements are fully specified and are tested in the Proof of Concept stage.
Even at the early stages of implementation the team may be able to cope on a ‘part time’ basis but the evidence is that this approach is not sustainable for very long. It is important to remember that search touches everyone in the organization who has access to a desktop, and any failure to locate business-critical information on a timely basis could have serious implications for the organization.
Enterprise search vendors tend not to be too explicit about the scale of support needed following installation of their software. There is a concern that prospective customers are aware of how much support is needed they may not proceed with the purchase. Even if the purchase of the software has been made some time in the past there should be no reason why a search vendor should not be willing to share information about the size and roles of search teams in other customers.
The support requirements are significantly greater when enterprise search is rolled out globally. There is likely to be a need for an Information Specialist for each major content language, especially in the case of German (where word length and complexity can raise some novel issues) and of course in ideographic languages such as Chinese, Japanese and Korean. These and other languages (Finnish is the classic example) will need attention paid to stemming and lemmatization and to seemingly simple issues such as the way that organisational names (such as OECD) appear differently in French (OCDE). This may not be a full time position but certainly the expertise needs to be available to the search team.
For similar reasons there is a good case to be made for an Analytics Manager for each business area in a highly diversified global corporation. The search terms used for one section or subsidiary of the business may well be very different from those in others. Investment banking and retail banking would be a good example.
Certainly there has to be a Search Support Manager in each major country, or at least each region (Europe, Asia/Pacific, North America) and language issues have to be born in mind. Although people may well speak several languages in business situations they will prefer to search in the language in which they have the best command, so Spanish language search and support in South America is very important.
As a result the numbers can add up:
One Information Specialist (IS) for each major language (x)
One Search Analytics Manager (SAM) for each business area (y)
One Search Support Manager (SSM) for each major country (z)
Core search team of at least three for search management and vendor relationship management:
| Team size = x(SAM)+y(SSM)+zC+3 |
So for an organisation operating in English, French and German, with two main business areas, and with significant business operations in the USA, France, Germany, Dubai, New Dehli, Seoul and Beijing the numbers work out at:
| Team size = 3(IS) + 2(SAM) + 7 (SSM) + 3 |
That totals 15 members of staff, and for the purposes of this calculation local IT support has been excluded.
This may seem quite a considerable team, but it can be interesting to find out how big the support teams are for enterprise applications such as an HR portal, an enterprise resource planning application a business intelligence application or a high-end document management application. Why should enterprise search be different?
Many companies set up a global Centre of Search Excellence (CSE) to bring together staff with specialist expertise that may not be available in all business centres. Certainly staff in the Information Specialist and Search Analytics roles may not need to be located in the countries that are supporting, but this is certainly not the case with the Search Support Managers.
The core issue is where this CSE will be located. The obvious answer is in the country where the global headquarters is based and for a great many companies this may be the United States. Then the problem arises of where in the USA given the three-hour difference between the East Coast and the West Coast, and in the case of the latter in particular the resultant time gap between the CSE and operations in mainland Europe of some nine hours – a complete working day.
The decision is not an easy one and needs to take account of:
The location of staff with the appropriate specialized skills
The location of the technical support desk of the search vendor and/or implementer
Which operations/countries are going to present the most complex search enquiries?
The reporting line for the Search Manager
The ability to provide real-time access to support from as many of the core geographic areas possible
In the end the decision is likely to be political/organisational than pragmatic, and the downsides of the resulting decision need to be considered in detail and addressed. A Search Center of Excellence can also be helpful in advising subsidiary companies on the selection and implementation of individual search applications.
It is not easy to find people with the skill sets needed to meet these roles and responsibilities. In the USA the iSchools have paid more attention to teaching information retrieval and search technology than is the case in Europe, and currently there is no full-time undergraduate course in the world specifically on search and information retrieval. The iSchool at the University of Sheffield is a world leader in information retrieval research, and offers a set of modules on information retrieval to students reading for a degree in Informatics.
Set out below are the topics covered in the course as an indication of the skills that are required in a search support team.
The historical development of information retrieval
Distinctions between search and browse
Relation between IR systems and databases
A general architecture of IR systems
The various properties of text documents, such as structure, semantics and metadata
The concept of indexing, in particular full-text indexing
The use of a pipeline for pre-processing text documents that includes tokenization, the use of stemming and morphological analysis, selecting subsets of terms based on term weighting and the removal of non-content bearing words
Mechanisms for matching queries with documents, including the use of the inverted index
Boolean and Best Match (e.g. vector space and probabilistic) modes of retrieval
The notion of term weighting
The use of query expansion (through relevance feedback) to maximize the success of matching queries and document representations
The concept of an inverted index to improve search efficiency
Understanding the user and their interactions with an IR system
Supporting user interaction and search user interface design by effective design for interactive search
The evaluation of information retrieval systems including the different approaches for evaluating systems
The use of test collections by system developers
Measures of system effectiveness and user-oriented issues
The basic principles of web searching
General purpose vs. specialized search engines
The architecture of general purpose web search engines (e.g. Google)
Crawling and ranking search results
Search engine optimization
The evaluation of enterprise search
Architectures for enterprise search
Commercially available systems
Differences between enterprise and web search
Without a good, structured, understanding of these topics within the search team the team will be flying blind, relying on trial and error to improve search performance without understanding either the fundamental principles or the way in which they have been encoded in technology. Is it a risk your organization is willing to take?
Because most employees will be using the search application there are likely to be quite a number of calls with queries about the way in which the application seems to be working. A particular challenge of search is the technical complexity of the application, some aspects of which IT departments may not fully appreciate or be able to fix. Relevance tuning is just one example.
Most organizations have some form of IT Help Desk, and larger organizations will have a means of issuing ‘tickets’ that log the query, track the progress of the resolution and provide a database that can be analyzed for trends in the types of problems that have been encountered with hardware, software and network components.
When it comes to search there are four decisions that need to be made:
Should the IT Help Desk be the first point of call for any search enquiry?
Should the IT Help Desk be staffed with the skills needed to handle all search enquires?
Should there be a separate Search Help Desk?
If so does the Search Help Desk become the first point of call for search enquiries or act as a support to the IT Help Desk?
The situation becomes more difficult with multi-national operations as there could well be local IT Help Desks with only limited expertise in the main corporate applications. The use of these in some countries may be quite limited but there could be many users of the search application, perhaps in a local language as well as in English.
There is no ‘best’ model for Help Desk management and much will depend on the skills and resources of the IT Help Desk(s). In the early stages of the implementation of an enterprise search application many of the enquires may be about connectivity and technical performance but as the application beds down there will be more about content and relevance ranking.
Search implementations tend to bring up some difficult issues around security management and regulatory compliance. Managing information security is a substantial business and IT task to ensure that documents are only able to be searched and opened by users with the appropriate level of security clearance. It is quite possible that the existing security access protocols will need to be revised to take account of the power of the search application to find information that it is not supposed to find, or more correctly to find it and yet not deliver it unless there is a business/security case for doing so.
It is not uncommon for organisations to highlight the importance of not disclosing confidential information without putting any guidelines in place about how to decide who should be able to have access to specific information. Security has to be managed at the level of individual named employees and their Active Directory metadata.
Potentially even more challenging is meeting the requirements of data privacy legislation, especially if the organisation is subject to EU legislation, which extends to anyone from any country that is working in the EU. The problems of conformance are not just related to intranets. . For example, sending details of an employee’s cv to the USA from the UK as the result of a search being carried out in the USA without the consent of the employee could be in breach of the legislation. There is a view by some companies that if they only send information to other sites of their company then the legislation does not apply. This is not the case, and full consent needs to be obtained. This is because there is also a very important distinction between personal information and sensitive personal information in EU legislation.
Sensitive personal information covers:
The racial or ethnic origin of the data subject
Their political opinions
Their religious beliefs or other beliefs of a similar nature
Whether they are a member of a trade union
Their physical or mental health or condition
Their sexual life
The commission or alleged commission by them of any offence
One of the key issues is that a person has to give their informed consent for this Sensitive Personal Information to be held in a database. Some intranets have an internal staff newsletter. In the interests of good communication there might be a news story about how a member of staff had been ill, but was now coming back to work for a few days a week. This could be regarded as sensitive personal data, as it related to the health of the person, and this information should not be able to be disclosed to anyone outside of the EU.
Many consulting projects, especially in human resources and change management, may require the consultants to check on personal information about employees. Using a corporate intranet from a single site to gain access to this information is likely to be forbidden, and of course if this information is to be held by a third party such as a consulting company, or an outplacement agency, then the employee’s permission needs to be sought in advance. The employee also has the right to ensure that the information being held is correct, and this will require companies to implement intranet systems so that the employee can only see their own record, and not that of others. For employees that have left the company this right will extend as long as their file is maintained, which also gives rise to a range of problems, such as the time that a company should reasonably maintain that file.
In reviewing search logs there could be searches on voluntary redundancy, sexual harassment or discrimination or for the addresses of senior staff. All these might be taken as an indication that the person carrying out these searches was planning to take redundancy, sue the organisation for sexual harassment or discrimination, or send the addresses of senior managers to an animal rights activist group. The extent to which search logs might be construed to contain personal information has not yet been tested in the courts.
Data privacy compliance is especially important to take account of in the use of photographs on staff databases. Because a photograph will almost certainly contain information that enables a person’s racial or ethnic identity to be inferred (even if incorrectly) staff photographs fall under the provisions of Sensitive Personal Information, and specific permission needs to be sought from each member of staff before their photograph is added. This has to be informed consent, so the member of staff needs to understand the implications and cannot be penalised for not giving consent. The fact that the photograph is on a staff badge does not mean that the photograph can be used for a staff directory. The photograph on a staff badge is there to enable security staff to ensure that the badge is being used by the designated badge holder.
On 25 January 2012 the European Commission published a proposal for a new regulation on the protection of individuals with regard to the processing of personal data and on the free movement of such data. There are some substantial changes proposed to data privacy legislation, in particular the move from a Directive to a Regulation as a means of gaining greater harmony over Member State data privacy implementation. The risks of non-compliance under the Draft Regulation are substantially greater than under the current legal framework and, for the most serious breaches, a national data privacy authority may impose a fine of up to a maximum of 2% of a company’s annual worldwide turnover. The new regulatory regime will come into force in 2015/2016 but the work needs to start soon on identifying any potential areas of non-compliance.
It is essential that the advice of lawyers specializing in data privacy is obtained. It is likely that in-house legal teams will not have any substantial expertise in this complex area, especially when an intranet needs to be compliant with a number of different national legislations. Currently around 40 countries have some form of data privacy legislation.
Another area where legal advice is important is the management of a situation when a court requires the company to disclose information for a court case or a regulatory compliance check. Here the processes in the USA are somewhat different to those in most other countries, and are set out in Chapter 26 of the Federal Rules of Civil Procedure. The implications are complex and potentially costly and should not be put on the list of “This can never happen to us.”
It is important to have excellent lines of communication deep inside the organization. It could be that just one business unit is having a substantial problem with searching across particular repositories, and may not have the time or inclination to report back to the Search Support Team.
This is where the appointment of search liaison specialists in as many business units as possible can be very valuable. They are the eyes and ears of the Team, providing feedback on their own user experience and listening for good news and bad news about the search experience coming from their colleagues. These liaison posts should be visible ones, so that users know who to go and talk to about their search experiences. The liaison specialists should be well trained in the use of the search applications so that they are in a position to provide on-the-spot assistance and to look at failed searches with an experienced eye. This liaison role needs to be included in the job description of the employee. Their manager should appreciate that if the employee moves from their current position then the incoming employee may not be the best fit for the liaison role, and that someone else may need to be found.
One of the major challenges in establishing the search team is deciding on the reporting line. It may well be that the team is made up of staff seconded from various departments, and as always in these situations the clarity of the reporting line is even more important than is the case with an intra-departmental team.
The situation with the search team is just the same as with the intranet team. It is difficult to find the optimum position for an intranet team and as a result it may report to Internal Communications, HR, IT or an important Line of Business manager. Having the Search Manager for Enterprise Search report to the Corporate Intranet Manager is not sensible. The scope of enterprise search is potentially much broader than is the case with just intranet search even if in the first instance the search application is implemented for the intranet, and the Intranet Manager may be unwilling to lose the full-time support of their Search Manager as the role develops.
A distinction can usefully be made about the reporting line during the selection and install process (which might well be to the IT Director) and the on-going management of search. In this latter case the requirements are more likely to be driven by the business rather than the IT infrastructure.
The decision is not of course just one of operational responsibility but also of budget. Compared with many enterprise applications enterprise search license costs are concerned are relatively low, and only in very large implementations are the license costs going to be substantially more than $500k. The costs are in the search team, and lines of reporting usually align to budget ownership.
It is not possible to give a definitive recommendation on reporting lines, other than the Search Manager has to be able to make things happen across national and departmental boundaries, and therefore needs the support of a line manager to is able to provide the appropriate level of global support and influence and who appreciates the need for staff support after implementation.
One of the core responsibilities of the Search Support Team is to carry out a range of searches on a regular basis to reproduce the results that others are being presented with. It may be difficult for the Team members to judge relevance but they should be on the lookout for results that look out of place. It may be because they are several years old, have poor titles or are in file formats that may now not be supported by the company.
Another set of searches should be carried out on an agreed set of core documents, such as the main HR policies, pay grades, health and safety topics and corporate publications. Some of these may only be important on a cyclic basis, such as the protocols for carrying out employee evaluations. All of these may be prominently displayed the home pages of other applications (notably the intranet) but that is not an excuse for checking that these documents are easy to find from the search box as well.
It can also be useful to talk to departmental managers about documents that they are responsibile for that should be easily found by employees. Take a list of these documents and see how easy it is to find them using some obvious query terms. The results can be surprising! This process will show where additional metadata needs to be added and previous versions need to be archived.
A feature of many search implementations is the concept of Best Bets. These are documents that are positioned at the top of certain searches to ensure that the results presented are seen in the context of importance of key documents. These best bets need to be linked into specific search terms, so that (for example) any search on the security [risk] always presents the corporate security policy at the top of the search results. The decision on what documents to highlight as Best Bets has to be made in conjunction with the appropriate specialists in the organization. It must never be the sole responsibility of the Search Support Team.
These Best Bets need to be reviewed on a regular basis. Many corporate documents are updated on an annual basis, and the current one needs to be replaced by the up-dated document as soon as it is available. Ideally there should be an owner of every Best Bet, so that if a user has a query about the validity of the Best Bet they can quickly call or email the person responsible for selecting the document. This person may not be the author of the document, because the author may have left the company or moved to another position, or not had the authority to decide that the document is indeed a Best Bet.
Some companies use the concept of Best Bets to highlight experts in the company. A search for [nuclear reactors] in an engineering company may more usefully highlight the name of one or more nuclear engineers than a multitude of standards on how to manage nuclear reactors.
Usability tests are an important element in developing web sites but there is much less support for usability testing for intranets, search applications and other enterprise applications. Search usability in particular seems often to be totally ignored. The excellent Useit.com web blog of Jakob Nielsen offers very little guidance on search usability. One of the excuses that often given is that since everyone has their own view of what is relevant there is no point in carrying out usability tests. That misses the point about search being a dialog and the need to ensure that the search interface supports the dialog not only up to the point of a set of results being displayed but then supports the user in reducing the total number of results down to manageable list to browse through.
The other common excuse is that usability is too time-consuming and expensive to carry out. The response to this has to be that the company could be at risk from an employee not being able to find the information that could have made a significant impact on business performance. If the company is willing to take that risk then certainly there is no point in carrying out usability tests, but that risk could have a very public impact on the reputation of the company.
Because of the complexity of search user interfaces compared to the options offered on most web and intranet pages usability is not an option but a necessity. The interface situation is going to become even more complex as employees make use of tablet and smartphone devices to access enterprise search applications.
Fortunately some very good books have been written on the subject of search user interface design and testing, and they will be of more assistance than an inadequate summary in this book.
Search logs are a critically important diagnostic tool. Without adequate log analysis any search implementation is flying blind, potentially a waste of investment that has been made in the application. The frequency of analyzing the search logs can only be decided by experience. Monthly may be too frequent for a review of the top searches by query as these will probably not change a great deal from month to month. However a review of searches that seem to have failed should certainly be carried out at least monthly, because a failure to find information could have led to a loss of a business opportunity.
In the case of intranets search logs should be analyzed in conjunction with click statistics on the web pages. In the case of one multinational company the search logs suddenly showed that there were several thousand searches being carried out each month looking for [conference call] or [teleconference number]. It turned out that the internal codes for the corporate teleconference network had been listed on the home page of the intranet, but in a design change these had inadvertently been removed.
The impact on the workforce was considerable, because searching for these terms produced a lot of results along the lines of “Please use the teleconference service for this discussion” but did not provide the number itself. This turned out to be about result #50!
Some of the useful log reports are the following. The number of searches has been arbitrarily set at 50 for the purposes of this book but in practice the number will need to be decided on an ad hoc basis as the scale and value of the log files becomes apparent.
The number is arbitrary but the purpose is to see what are the most popular searches, and some of these could well be a result of poor information architecture on the intranet(s). Even if the enterprise search is working across multiple repositories it is likely that the intranet will be the starting point for the majority of searches. For each term used the reason for it should be fairly obvious. Often the significance of the top terms only becomes visible when the terms are clustered together. In the case of the teleconference number issue there were six different search terms. Individually they came fairly low down the top 50 listing but when aggregated the search theme came third in the overall listing.
Many of the terms in an enterprise search log will be applications, as users search for an application by name or purpose that they have perhaps not used for some time. These need to be discussed with the application owners to understand why users are having to use the search box to find them.
This log will show where there may be gaps in content, or where a search query is being typed incorrectly and the internal directories are not suggesting an appropriate alternate. A user may have chosen the wrong collection or used the wrong acronym for an internal project or product. Enterprise search users will have the expectation that the search application will find something of relevance and finding nothing at all is probably the biggest single reason for not only dissatisfaction with the implementation but possibly a permanent attitude that using the search application is not worth the effort. The end result will be that decisions may be made on inadequate information, to the detriment of business and personal performance.
This is a situation that needs careful scrutiny. Users are being presented with a list of results but either these are so wide of the mark for some reason or the user realizes that they need to go to a section of the intranet or some other application to find the information they are seeking.
Some of these may need to be promoted to best bets. A review of the list may also show that users are viewing documents that are in fact out of date or not the best match. These insights can only come from search team members who know the significance of these failures and can allocate the time to find out why users have selected the documents
This analysis should give some indication of where the relevance tuning needs attention, especially if the documents being retrieved were some way down the relevance ranking. There is an expectation that the enterprise search application will be able to deliver relevant information within the first few pages of results. Although unrealistic these expectations need to be acknowledged and solutions found to the user being presented with perhaps 4000 results.
Selecting best bets and then ensuring that they remain best bets is an important role of the search support team working closely with experts in the business. Monitoring any fall off on best bet clicks needs immediate analysis because almost nothing is more frustrating to a user than being presented with an irrelevant document at the top of the list of search results
There should always be a feedback form on the search page. There is no benefit from having a highly-structured set of questions. Users will not remember the steps they went through and at that moment in time will not want to spend 10 minutes reliving their past. Provide a free-text box and ask users to briefly outline their search experience (good as well as disappointing) and ask for contact information so that a member of the search support team can follow up with them. The form should of course capture the query terms used so that the search can be replicated before, and then during, the discussion with the user.
Training is not an activity that starts and stops in the implementation phase. It is not uncommon for 10% of employees to leave and arrive in the course of a year, and new employees will certainly be stress-testing the search application within minutes of sitting at their desk or switching on their smartphone. The communities that need to be trained and supported include:
IT department
Managers of applications that are being indexed
A good communications strategy is very important in achieving a high degree of user satisfaction. Some of the elements of this strategy might include:
A search advice section on the corporate intranet, perhaps positioned close to the search box
A blog from the Search Support Team with success stories, tips for good searching and information about upgrades and enhancements to the search application
Presentations and workshops given by members of the search support team
Best bets owners talking about how valuable users have found best bets information
A wiki which can be used to record issues that have arisen and the progress towards fixing them, and also to post advice on how to get the best from the search application
Establishing search communities of practice in business units
Publishing log information on a regular basis
Try to find some search success stories, perhaps by talking to people who were critical of the existing application and are how (we hope) very enthusiastic about the new search application.
Communications is as much about listening as publishing and so users should be encouraged to talk to members of the search support team.
Managing search is achieved by skilled people who understand the technology and capabilities of the search application working closely with users at all grades, roles and responsibilities and in all locations. That is a tough call and a significant investment but without the skilled people the organization is putting its business activities, objectives and reputation at risk. There is a lot of work to do every single day and with rare exceptions in smaller organizations being a member of the search support team is a full time position.
You'll find some additional information regarding the subject matter of this chapter in the Further Reading section in Appendix A.