Quality: It’s a Judgment Call

by Saul Carliner and Lola Fredrickson

Imagine this. You run an information development agency and have been working for five years to land a particular account. The director of information systems at that company finally invites you to bid on a project.

The project is by no means yours, however. Two other local firms are also bidding on the business. To increase the likelihood of winning the project, you assign one of your most experienced and skilled project managers to prepare the proposal. She spends a lot of time with the prospective client, trying to understand the client’s needs and to prepare a proposal that meets those needs. Because of the project manager’s experience, you have strong confidence in her skills and do not spend much time overseeing her work.

At the same time that she is preparing the proposal, the project manager is also grappling with family problems. Although you are aware of these problems, you are caught off guard when, the evening before she is scheduled to meet with the client to present the proposal, the project manager calls you to tell you that she’s quitting your company immediately and leaving town. But she has faxed the proposal to the prospective client and promises to bring you a copy at 3:00 p.m. the next day, two hours before your meeting with the client.

Although concerned, you feel that the situation is under control¾ until 3:15 the next afternoon, when you realize that the project manager hasn’t shown for her appointment and probably isn’t going to. How can you face the client, knowing that he has seen the proposal and you haven’t. In fact, you don’t know anything at all about the project and the one person who can tell you has apparently skipped town.

The situation is seemingly hopeless. But it’s not. This is a true story and the agency won the account. The story of how the agency won the account demonstrates the role of quality in information development. (You read correctly. The story of how the agency won the account demonstrates the role of quality in information development.)

This story also demonstrates a characteristic that goes hand-in-hand with quality: judgment. But before we conclude the story and explain how a demonstrated commitment to quality and good judgment saved this seemingly unsalvageable situation, we would first like to provide you with a background on the two and how they interrelate. Specifically, we would like to:

  • Introduce you to the three components of quality
  • Describe each of those components in detail, explaining what they are and how they provide “judgment calls” to information developers

The Components of Quality

What the Components Are

If one were to peruse the agency’s list for providing quality proposals to prospective clients, “make sure the project manager doesn’t skip town” is not likely to appear on the list. What does appear on the agency’s list are those components that most people have come to associate with quality. These components of quality are:

  • Providing quality information products
  • Using consistent processes to develop these information products
  • Providing excellent service to the clients who request that you develop information products for them (Davidow & Uttal, 1989, p.196]

The following figure shows these three components of total quality.

The Components of Quality for Technical Information Products

That’s the purpose for the such lists used by this agency and many other information development groups: identify the components of quality and all of their subcomponents, make sure that you routinely provide them, and measure to make sure that all of the components and subcomponents are always present.

Why Judgment Is Essential to All Three Components

Sounds simple? There’s one hitch. No checklist or measurement system can account for everything. For example, no checklist or measurement system can account for the problem that occurred in the example about the information development agency. Nor can such a system account for the agency’s ultimate success. That’s because providing quality is more than checklists and measurement systems. Providing quality requires judgment on the part of practitioners.

Judgment is an essential element of success in providing any service. Although the fruits of our labors usually are a tangible product, such as a manual or a course, we information developers work in a service industry. The manuals and courses are intended to serve people–not just the users who read them but also the clients who request and pay for our services.

Consider that we begin all of our work when a client has a request ¾ not when a user contacts us. Similarly, the work is finished only when the client says it’s complete and that he or she is satisfied, not when our work has passed a usability test or we think the client is satisfied.

Customer service, then, is an important element of any successful quality program. It can be viewed in two ways:

  • As a routine for handling customers. With simple and generally routine types of tasks in the service industry, organizations can devise a checklist-like approach, stating a standard way of handling each situation and making sure that workers follow it. For example, in information development, we usually go through a series of checklists before submitting a project for final production.
  • As doing whatever is necessary to please the client. Because we don’t always know what “whatever” is, we need to leave some room open for judgment. Sometimes “whatever” is an extraordinary, once-in-a-career situation, like covering for an employee skipping town. Sometimes, “whatever” is adjusting to an unexpected reaction to an otherwise typical situation, such as a client who does not like your writing style.

The next several sections explain how judgment plays a central role in each of the three types of quality.

Product quality is defined as conformance to requirements. When referring to the manufacture of tangible products such as cars and computer hardware, conformance to requirements is a definable exercise. The requirements usually come in two varieties. First are customer requirements that identify what the product should be able to do, the conditions under which the product should perform, and the degree to which the product should work. For example, most consumers expect to drive cars for at least 100,000 miles with only routine maintenance.

Second, these customer requirements are translated into product specifications: plans for building the product with the features that customers requested. These product specifications are usually technical in nature and provide limits for acceptable parts. For example, a car window is designed to be a specific size, and there are only minute variations that can occur or the window won’t fit in the car.

The quality of a product is usually measured in these ways. These are:

Type of Measurement Description
Technical Were all of the parts of the product built to the measurements provided in the engineering plans? For example, do the measurements of a completed car match those in the engineering plans?
Performance Does the product operate under the conditions and to the degree requested by the customer? For example, do all of the cars travel for at least 100,000 miles and only require routine maintenance?
Satisfaction How do customers and potential customers perceive the product? For example, in a survey of car owners, how do car owners rate the car?

In the past, the information development community has taken a manufacturing approach to quality–conformance to standards. We have identified these elements of product quality:

Design The overall appeal of information to readers
Editorial Mechanical aspects of the text
Production The physical look of the product
Usability The ease with which readers can use information

The following sections describe each element of product quality.

Design Quality

What Design Quality Is

Design quality refers to the overall appeal of the information to readers. This appeal comes at two levels: the overall approach to the information– its structure, the appropriateness of its content, and choice of communication media–and its visual appeal. This is called document design or information architecture. The ultimate goal of effective information architecture is to provide readers with the information they want, where and when they want it.

Although we have no single measure of effectiveness for design quality, we have developed many partial measures. These include design formulas for the ratio of text to white space on a page, the length of a line of text, and the number of subheads and index entries on a page.

How Information Developers Use Judgment to Achieve Design Quality

The presence of certain design elements alone does not assure quality. For example, although more index entries tend to indicate that more information is available to readers, the index entries might not provide the right information to readers. The index might not include synonyms and no measurement system can track this. An indexer must effectively choose terms for the index. Although the principles for choosing index entries can be described, ultimately, the choice of index entries is a judgment call.

At a broader level, the information might be superbly crafted but might not provide the intended results. For example, a bank once noticed that its tellers were not performing well on the job. The manager of tellers asked to have a training course developed that taught tellers how to perform their jobs more efficiently. But job performance remained the same after training. Upon further investigation, the trainer learned that the tellers knew how to perform their jobs, but did not feel the incentive to do so. The tellers at the first bank had learned that tellers at a bank across the street made 50 cents more per hour and so the tellers at the first bank adjusted their work performance to their lower pay scale. Information would not solve that problem; a pay increase would. A checklist-like approach would not instruct an information developer to ask for a salary comparison. Only by listening to the tellers and using judgment could an information developer determine what to do.

Editorial Quality

What Editorial Quality Is

Editorial quality primarily refers to the mechanical aspects of the text. Does it flow well? Are the spelling and grammar correct? Are numbers used consistently? Are lists punctuated consistently?

To ensure that published text is “quality,” we in the information industry have set up an elaborate system of editorial standards. At the heart of these standards are dictionaries and style guides. We consult dictionaries for the appropriate usage and spelling of words. We consult style guides for the consistent use of terminology, punctuation, and similar mechanics.

As a resource, editorial guidelines help us ensure quality, especially in the area of consistency. Consider, for example, the large library of documents that accompany a complex computer system. Each document is usually written by a different author and, if each author were to use different terms and different punctuation for the same types of things, readers would be confused. Readers perceive such differences as differences in meaning, not as mere differences in approach.

How Information Developers Use Judgment to Achieve Editorial Quality

Standardization can only go so far, however. Consider that some organizations have as many as three style guides that they use¾ a standard style guide, a guide of corporate exceptions, and a guide of project exceptions–to minimize the confusion of inconsistencies.

With so many style guides, information developers often have more standards to follow than they can keep track of. The likelihood of any single document conforming to all of the standards is slim. Information developers must use judgment in assessing whether a situation they encounter in their work requires consulting the guidelines.

Furthermore, many of the guidelines in a style guide are interpreted as rules rather than as what they are¾ guidelines. For example, one issue that consumes information developers is the correct manner for punctuating lists. Do the first words of list items begin with lower or upper case? Do we put periods at the end of each list item, just the last list item, or none of the list items. The truth is, any of the systems is correct as long as you only choose one of them and use it consistently throughout an information product.

The effective use of style guides and dictionaries, then, requires judgment, too. If following a guideline will enhance readers’ experience with information, we should use it. If it will not, we should disregard it.

Production Quality

What Production Quality Is

Production quality refers to the physical look of the information product. For print materials, production quality refers to the printing specifications. For online and audiovisual materials, production quality refers to the quality of the programming, audio production, and video production, as well as to specifications of the packaging, including the type of paper used as well as the ink used on the paper. For audiovisual materials, production quality refers to physical aspects of the materials, such as the consistency of sound levels in the audio track, the smoothness of transitions among scenes in a video, and the clarity of photographic and videographic image.

We ensure these types of production quality through a few key activities:

Activity Description
Proofreading Proofreading is one of the most misunderstood aspects of production; most people confuse it with editing.Proofreading is matching input text with output text; it is not correcting previously undetected errors. In fact, in good proofreading, errors on input should match errors on the output.
Defining printing specifications These specifications include identifying the type of paper to be used in printing, the type of printing process to be used, the type of inks to be used, and the like.Press checks conducted before final printing help information developers make sure that the printed text meets the printing specifications.(Like proofreading, press checks are a misunderstood activity. Many people think of press checks as a last review copy. They are not. Press checks are only intended to give clients a chance to make sure that the printer followed all of the instructions.)
Identifying programming specifications and conducting a system test These activities ensure that the online information works as planned. For example, the system test should make sure that when users select a hypertext term, the system links the user to the appropriate topic.

How Information Developers Use Judgment to Achieve Production Quality

Although we have tried to create routines for ensuring production quality by establishing formal processes and using standard tools and terminology, the process is not judgment-proof.

For example, what do you do if you are proofreading a document and identify a major inaccuracy in the text? If you are strictly following proofreading guidelines, you would leave the inaccuracy as is. Your best judgment would indicate, however, that the problem should be identified and corrected before the information is published.

Usability Quality

What Usability Quality Is

Usability quality refers to the ease with which readers can use information. Information developers assess usability on three criteria:

  • Ability of users to complete a given task
  • Speed at which users are able to complete the task
  • Satisfaction that users feel about their ability to perform the task

Some approaches to information design promote usability, such as the use of white space and minimizing the number of menus and options users need to choose to perform a task. JoAnn Hackos calls these minimal barriers to use (1994.)

Because information developers can apply these principles to most information products, some organizations have tried to identify all of the design elements that promote usability, develop checklists of them, and use these checklists to assess the usability of their information products. The U-metric, discussed elsewhere in this book, is one such effort. But, for the most part, these checklists of quality are so cumbersome that organizations have ultimately chosen not use them.

How Information Developers Use Judgment to Achieve Usability

The mere presence of all of these design elements does not ensure usability. Ultimately, the act of preparing usable information is specific to the subject matter. For example, one principle of usability is presenting information at an appropriate level of detail.

But this can only be assessed on a case-by-case basis. Similarly, providing all of the information that readers need and providing it in an appealing way can only be assessed on a case-by-case basis. Furthermore, what is “complete” and “appropriate” varies among users; two users could easily provide two different assessments.

Information developers must use judgment in assessing these reviews. If members of the primary audience say the information level is appropriate yet members of the secondary audience feel otherwise, the information developer must decide how to proceed.

Usability is ultimately assessed on a case-by-case basis. Therefore, usability testing will prove more effective than a checklist in determining user’s ability to use a specific piece of information. This type of testing assesses not only the overall usability of an information product, but also finds specific impediments to quality so information developers can fix them.

Process Quality

What Process Quality Is

Imagine that you wrote a quality document. It has design, editorial, production, and usability quality. It has won awards from professional organizations like the Society for Technical Communication (the world’s largest professional organization for information developers) and rave reviews from the trade press.

But you needed six drafts and two years to produce this masterpiece. You forgot to include a key chapter in the first draft. The editor had a separate review cycle. You forgot to have the final draft copyedited before going into production and had to stop production at the end when you discovered major inconsistencies in the typefaces used for headings. This last minute change caused the schedule to slip by three months. Despite the glowing reception of your manual, the product itself is doing poorly because a competitor introduced a similar product while you were perfecting your masterpiece.

JoAnn Hackos comments on situations like these. She notes that, in their quest to achieve quality, many organizations believe that they can do so by merely “hiring good people, setting standards, and using good tools of the trade” (1994, p.14). But, as the previous example shows, these actions alone do not ensure quality.

Ensuring quality is more than what you do, it’s how and when you do it. To ensure that organizations provide with the services how and when they want them, in recent years, quality experts have tried to find a way to apply quality standards to services. In those industries where they have done so, quality experts first identified the best practices that employees use in delivering a service and try to extend those practices to all employees.

For example, in the drive-thru window of a fast food restaurant, customers expect that fast food will be delivered and served courteously, and that the package will contain the food that they ordered. So McDonald’s guarantees that their service will be fast and friendly, and that all orders are double-checked for accuracy.

Process quality can be applied to information development, too. Although we like to think each project is unique¾ and certainly each project has its unique characteristics¾ the similarities among projects are pronounced and we can identify the best practices used by information developers to address these characteristics. For example, each project follows a similar sequence of events from start to completion, going through a series of drafts before final production. At each milestone in this sequence, similar activities occur.

When drafts are complete, for instance, information developers usually send them out for review. Certain approaches to activities are more likely to lead to success than others. Consider that editors could write out all of their comments, but by using standard proofreading symbols, editors reduce both the number of marks needed to make a comment and increase the likelihood that the notes will be understood.

Many organizations have found that by documenting the process by which information is developed and stating how activities should occur during that process, they can improve the quality of their information products. These written procedures are the basis for process quality and a means of ensuring that information developers publish the information on a timely basis and within budget.

In information development, process quality involves:

    • Establishing a sequence of activities and the time needed to complete those activities. When establishing this sequence, information developers often identify redundant steps and find ways to “double up” steps that can be performed simultaneously. For example, editing and technical reviews used to happen at separate times but now most organizations have them occurring at the same time. Doing so can significantly cut the length of the development cycle.
    • Ensuring that certain activities occur and that they occur in consistent ways. These activities are usually represented as a checklist. By developing these checklists, information developers avoid costly omissions in the process.

For example, consider reviews. A review is a review is a review. The review process for one type of information is remarkably similar to that of another; the only difference is what is being reviewed.

What can you standardize in this process? You can write one standard review letter that identifies all of the issues that reviewers should attend to in the review process and then tailor the letter for the information being reviewed. You can estimate the amount of time needed for reviews, based on the size of the project, so reviewers have adequate time. You can standardize the method of returning review comments so they are properly handled. You can also standardize the method of conducting a review meeting.

Identifying which activities occur at specified points in the process also helps regular clients know what to expect; the conduct of these activities helps new clients learn a publications approach.

    • Establishing a schedule and budget for the process. Less experienced information development groups generally take a best guess at these but, with experience, information development groups develop extensive formulas for accurately determining how long specific activities take and how much those activities cost.

The better the refined information development group’s formulas for estimating schedules, the more accurate their budgets and the more smoothly the development processes go.

How Information Developers Use Judgment to Achieve Process Quality

Even when you have a well-documented process for developing information and a well-refined formula for estimating schedules and budgets, you have many opportunities for exercising judgment about the process for developing information. Consider that, in some cases, you need not perform every step and by eliminating the unnecessary ones, you can reduce the overall development time.

Suppose you are making minor revisions to a user’s guide. The only major change is the addition of two menu options. Your development process requires three drafts but you probably do not need to develop three drafts to make sure the information is correct; you can probably do so in one or two. You might therefore make the judgment call to eliminate a few steps in the development process.

Similarly, despite your best efforts to estimate their size, projects often change scope during the development process. For example, after completing the first draft, the product developers might have added a new set of features to the product. As a result, you need to add a chapter to a manual and several screens to the online help system. Because of the additional work, your schedules and budgets are no longer accurate and you need to negotiate new ones.

Customer Service

What Customer Service Is

Suppose you have defined the elements of a quality information product. Suppose you have developed an effective process for creating information products. Your products might still be panned by your clients¾ because you failed to effectively serve them. This last aspect of quality, customer service, is the one that receives the least attention in the literature on quality in information products, but demands the most time and effort on our part.

One of the most difficult and least understood concepts among information developers is that we do not always write for our readers; we often write for our clients (we use this term, clients, rather than customer, because clients is the preferred term for organizations providing a service like ours).

Our clients are the people who authorize payment for our services. They might be internal to our organization, such as a software development department or the marketing department. Or they might be outside of our organization, such as a large corporation or a government agency. The following figure depicts the relationship among information developers, clients, and readers.

The Relationship among Information Developers, Clients, and Readers

Although many information developers do not have an opportunity to meet their readers, all of us have the opportunity to meet subject matter experts–the marketers, the programmers, the engineers, the scientists, and the managers–with whom we work.

These are the people who provide us with the information that forms the nucleus of our work, who tell us what and what not to include, who review drafts of our information products, who sign off on their technical accuracy, who compliment us when we do a good job and, more often than we like, give us grief when our work is not to their liking.

Most subject matter experts work for our clients and are one of our clients’ primary sources of feedback on our work. That’s why pleasing them is important. But subject matter experts should not be confused for the end users of our work or for our clients.

Managing the relationships between the information developer and the subject matter expert and the information developer and the client is essential to a feeling of success in our work. Some information developers have poor relationships with their clients and, as a result, feel dissatisfaction with their work. Others have outstanding relationships with their clients and, as a result, take pride in their work.

Managing the relationship between client and information developer is called customer service. According to Davidow and Uttal, customer service is

all features, acts, and information that augment the customer’s ability to realize the potential value of a core product or service (1989, p.22).

Zemke adds that the cycle of service begins with the very first contact point and ends when the customer considers the service complete (1989, p.22).

Exactly what do clients of information development services look for? According to a market study of people who contract for information development services, clients are interested in:

  • A good working relationship
  • Mutual understanding of each other’s business needs
  • Good scoping and estimating skills
  • Good management and business organization as evidenced by business documents such as proposals and invoicing
  • Good attitudes
  • The ability to approach each project as unique
  • The ability to offer a variety of peripheral services
  • Proven experience
  • The capability of suggesting many approaches to a problem (Fredrickson, 1992, p.396)

How Information Developers Use Judgment to Provide Customer Service

The Behaviors of Good Customer Service

The list above is just that, a list. Each customer uses his or her own judgment to define and evaluate service. What constitutes good customer service to one client substantially differs from what constitutes good customer service to another.

Adjusting to this difference in values requires judgment on the part of information developers, too. Good customer service is ultimately an approach to building a mutually supportive, trusting, and respectful relationship with a client. Using our judgment, information developers can choose to use certain types of behaviors promote or hinder mutually supportive, trusting and respectful relationships with clients. These behaviors include:

Behavior How this Behavior Promotes Customer Service
Personal Every client wants to feel unique and special.
Attention Providing personal attention to your clients is a means of making them feel that way. Extra touches such as thank you notes and personal phone calls can make a world of difference in making a client feel unique.
Dependability Clients need to trust that you will provide what you say you’ll provide. If you say that you’re going to provide a training manual, then you don’t provide a computer-based training course. If you tell a member of the programming staff that you’ll review a draft with someone from marketing, the clients want to believe that you’ll actually do so. If you tell clients that a service is going to cost $50,000, they will budget accordingly. If you charge more, they’ll not only be surprised, but feel betrayed.
Promptness Clients expect you to deliver materials when you say you will. If you promise information on Tuesday, they expect to receive the materials on Tuesday, not Wednesday or Thursday or whenever it’s convenient for you. Often, clients have already planned to use the material soon after you promise it. If you fail to deliver on time, not only do you look bad, but you have also made your client look bad. (Carliner, 1995).

Listening: An Art of Customer Service

Many good techniques are available for ensuring good customer service, but they all come down to this: showing the customer that you care and demonstrating that you are reliable. The best way to show that you care is to listen to what the customer tells you.

Ask clients what they want and then provide it to them. Although clients (both internal and external) hire us for our expertise and many know little about our work, they are capable of making appropriate decisions when presented with good choices. Our job is to fully inform them of their choices.

Informing clients of their choices requires judgment. In some cases, clients already know what they want yet we feel that a different course of action is more appropriate than the one suggested by the client. Convincing clients to take the alternate course of action requires judgment.

By listening to the client, we can identify ways that our solution better meets the stated needs of the client, without demeaning the client in the process. Following such an approach also shows respect for the client–and that shows you care.

Besides, if we ask why a client has chosen a seemingly foolish approach, we might learn that the seemingly foolish approach is actually a good one. That’s why our listening to clients is important.

For example, an electronic components manufacturer once asked one of us to advise the company on putting its information online. Had we heard what the client was doing ahead of time, we would have gasped in horror: the client was creating view files in WordPerfect. No information developer worth their salt would recommend such a basic and dull approach.

But upon listening to the client and its needs (consistency among sites, little or no education time for readers or developers), the implementation approach made sense–a lot of sense! Using this approach, the client was able to easily achieve its primary goals: consistency across sites and a quick move to online. Later, the client could convert its files to a more appealing format but, in the meantime, the files were already online.

In addition to listening to clients, set realistic expectations for them in writing. Identify cost, schedule, and quality issues with the client and explain how you plan to handle all three. To make sure that expectations continue to be realistic, provide weekly status reports and regular financial reports.

Customer Service: An Education Process

Ultimately, customer service activities build relationships with clients. This is sometimes called education because it is a process in which a client educates the information developer about its needs and information developers educate clients about the benefits we can help them obtain.

When the clients educate information developers, they are explaining the business they are in and how they develop and use information. That’s important to know; we can use that information to appropriately align our priorities. Setting priorities is a judgment call; we only respond to our needs unless we are aware of others we should consider. When information developers learn what matters to clients, we can set our priorities with regard to those of our clients.

When information developers educate clients, we explain the process we use to develop information, provide choices for clients, and explain how our services can help clients better meet their business objectives. For example, when explaining to a client what a project costs, we can also identify the cost savings the client would receive by pursuing a certain approach. As Redish notes, by using a well-designed form, an organization can avoid costly errors and rework (1994). By using a well-designed manual and online help, an organization can avoid unnecessary customer service costs.

As we get to know clients better, we can understand why they have the concerns they do. And it appears that as these relationships grow with time, we do a better job of understanding and meeting their needs.

So What?

Let’s return to our initial case study. When we left that case, the owner of the information development agency was supposed to go into a meeting in an hour and a half to present a proposal that the client had seen, but that the owner had not. Furthermore, the owner knew nothing about the project.

Left with minimal information about the account and none about the project, the owner of the firm had only one resource available to her: her own judgment. She had to rely on her own intuition about the situation and how to handle it. And her intuition led her to one of her core values: integrity. She is always up front with clients about situations.

Realizing that she did not know much about the account and that the only appropriate thing to do was to be honest, she met with the prospective client to withdraw her proposal. The owner of the agency explained the situation to the prospective client, adding that she could not in all honesty submit the proposal if she did not even know anything about the project. She closed by saying that one of the other vendors could, in all likelihood, serve the prospective client well.

The prospective client responded that the employee who left town had represented the agency well and that the proposal she submitted indicated that the agency better understood the client’s needs than any of the others bidding on the project. The client was so impressed by his previous contact with representatives of the agency and by the owner’s honesty that he asked how long the firm would take to get up to speed and be able to work on this project. One year later, the relationship between the client and the information development agency was still going strong.

When we think of quality, we often infer that our job is to make our work perfect. Quality work is far from perfect, but it is excellent. Excellent work, represents the best of product quality, process quality and customer service. But it represents something more; it represents good judgment.

In fact, we often have the greatest opportunity to build credibility and integrity with clients when we are presented with opportunities that require judgment. We often call these opportunities mistakes. But the manner in which we recover from these mistakes often builds more credibility with clients than our product quality. It is quality, total quality, that builds relationships. And it is the building of good relationships that builds businesses.


Carliner, S. (1995.) The eight secrets of successful work teams. Performance & instruction. 34(2).

Davidow, W. H. and Uttal, B. (1989.) Total customer service¾ the ultimate weapon. New York: Harper & Row.

Fredrickson, L. (1992.) Quality in technical communication: a definition for the 1990s. Technical communication. 39(3). p.394-399.

Hackos, J. T. (1994.) Managing your documentation projects. New York: John Wiley & Sons.

Redish, J. (1994.) Keynote presentation. Currents 1994. Atlanta, GA. Society for Technical Communication, Atlanta Chapter. February 18, 1994.

Zemke, R. and Schaaf, D. (1989.) The service edge¾ 101 companies that profit from customer care. New York: New American Library.

© Copyright 1996, 1999, 2001, 2010, 2012. Saul Carliner and Lola Fredrickson. All rights reserved.  If sharing or excerpting, should be properly cited.

About idmodelsandprocesses

Exploring, reporting, teaching, and advising on learning and communication for the workplace and consumers. saulcarliner.wordpress.com
This entry was posted in Business Forum, Business Tips, Project Basics, Project Forum, Project Tips and tagged . Bookmark the permalink.

Please add to the conversation.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s