Ever since I joined the MSTPC program, I have noticed a repeated theme throughout technical and professional communication literature. Technical communication often doesn’t seem to know what it is, what it does, or why it matters. I have read many research papers that seem insecure about the profession and try to pinpoint what technical communication is and who it is for. Notable technical writers like Tom Johnson have even tackled this issue in posts like “Why is there a divide between academics and practitioners and tech comm?”. In my Theory and Research class, I wrote my final essay about why researchers seem to explore the identity of the technical writer more so than other professions. I understand all professions do research about about their own field, but technical communication is one of the first fields I’ve run into that seems unsure of itself.
I saw some of these themes of identity in Blythe, Lauer, and Curran’s article “Professional and Technical Communication in a Web 2.0 World.” However, these authors seemed more sure about what technical communicators do and seem to be okay with the fact that technical writers are a diverse bunch with a wide skill set. They focus less on “What is a technical writer?” and instead, “What does a technical communicator do?” I particularly enjoyed and agreed with this quote from the piece, “In other words it is not enough in a Web 2.0 world to ONLY write effectively, you must branch out and be a master of many skills and tools.” Blythe, Lauer, and Curran explore these many skillsets and tools throughout the paper and it inspired me to create my own list of common writing tasks and tools I use in my day-to-day job as a technical content writer:
|Most often used types of writing||Most often Used Tools|
|1. White Papers||1. Google Drive (Doc, Excel, Slides)|
|2. Case Studies||2. Sketch|
|3. Blog / Syndicated Content||3. Slack / Email|
|4. Website / Landing Pages||4. UX Research tools like Ethnio|
|5. Blog / Syndicated Content||5. HubSpot|
|6. Press Releases||6. Asana|
|7. Advertising||7. WordPress|
|8. Strategy / Planning / Internal Sales documents||8. Survey Tools|
Most Often Used Types of Writing
I decided to create two different list of my writing tasks / tools to show the multifacetedness of technical writing. For instance, many of my “most often used types of writing” involves doing more than just writing (especially the higher ranked types). To create a strong white paper or webpage requires knowing design skills, information management, and UX expertise. Sometimes, I spend more time designing white papers and case studies with design tools than I do actually writing. This often makes me feel more like a visual designer than a technical writer, but I would argue that you would need to know skills from both trades to make a compelling document that is exciting to read.
Case Study Design
I created this document above to explain how Jacuzzi is using my company’s platform to create a connected hot tub. One of the biggest challenges with case studies is they offer a lot of information and most clients don’t have time to read them. As such, I believe it is important to create a document that would excite clients and can be read quickly. For this case study, I create a document that is easily scannable with data visualization and short paragraphs, while adding visual interests with color contrasts and visuals. I had to use design tools like Sketch to make visuals that draw the reader’s attention and use information management skills to organize the information in a way that is compelling.
The Importance of Tools
In “Using Social Media for Collective Knowledge-Making,” Longo discusses how technical communicators must become masters of ICT technologies. I would add to that and say that technical communicators must master more than ICT tools nowadays, but also must become a master of design, information management, task management tools, and more. The number of tools required to be a become a proficient technical communicator is only increasing too. However, while mastering all of these tools is helpful and certainly increase career opportunities, I wouldn’t say a technical communicator must be an expert at all of them.
The Bottom Line
As a marketing technical writer, it makes sense why I see visuals and design tools as such an important element of being a technical communicator. However, a technical communicator who focuses on creating internal documentation may not need to know the same number of design tools as I do. They may prioritize other skillsets and tools that I may not even know about. And that’s the benefit of being a technical writer – there is so many different routes and paths to specialize in. These wide range of skillsets and purposes make it hard to define what a technical communicator is, but it is certainly not a weakness. It’s something we should celebrate more.
Hart-Davidson hits the nail on the head, Content Management Systems (CMS) “do not do that work by themselves” (p. 14). A CMS can give a company what they are willing to put into it. They are not a solution, they are a tool. They are exactly what we make of it. Hart-Davidson states that “technical communicators typically come to play many different roles and deploy diverse sets of skills over the course of a career” when using CMS (p. 134). The roles mentioned must be assumed, but to successfully integrate the CMS into the company, the company must also integrate one or more company processes into the system to really benefit from it.
Training or some kind of education on how the company uses a CMS is a key to success. I’ve used quite a few systems and have seen excellent and poor uses of them in companies. When companies don’t have any rules around how a CMS is used, it becomes a free-for-all of good and bad information. It’s confusing. There is a plethora of online content available online for learning how to use and manage CMS systems online. However, even if you know how to use the system, this may not be how the company uses it. The video below only touches on some common mistakes in administrating SharePoint itself and it’s over an hour long.
Michael J. Salvo and Paula Rosinski both discuss “mapping” and “signposting” in information design (pp. 112-114). These concepts are a big part of UX and extremely important to ensure users can become literate in a system. I’ve found these levels of user interface designs are not well applied to most CMS. At one of the companies I worked for I had to redesign the front-end of a SharePoint site to make it more accessible and simplified for others in the company. This tells me that we have a long way to go in our design of CMS from a design perspective. Confusion in using the interface itself will almost surely create inconsistent data, especially when most people will have access to the system.
Process in how you use a CMS is key to making the system useful. Yes, it can allow versioning of documents, but when people are not required to update or sign off on documentation, it can create data that looks trustworthy but is not. Most systems have workflows integrated into them, but unless going through that workflow is a part of a sign off process for the deployment of a product, then why would people go through the hassle?
To make sure our documentation is trustworthy, my team and I will link our documents to specific releases of software. This way it will be clearer in what context you can assume a document may be relevant for. In terms of metadata we make sure that everything is under our team’s section in the system. We also have the option to tag certain customers if the document is specifically relevant to that context. The process we employ around this ensures that we do not have to continually maintain every document, but instead deploy documentation at our own pace and as needed.
I don’t think I could live without a CMS at a company these days, because the alternatives are much worse. But literacy in these systems remains a problem. This is probably due to the fact that the users are not the same as the customer. Additionally, I see many systems treated as a golden solution instead of a platform. It will be interesting to see how these systems and their usages evolve over time.
At my company, customers access much of our documentation by searching a central repository. Far and away, the most frequent feedback that we receive about our documentation is “I can’t find what I’m looking for.” So I was very interested in “Informational Design: From Authoring Text to Architecting Virtual Space” (Salvo and Rosinski) and their discussion of the necessity of search and retrieval and of designing our documentation for better navigation.
Salvo and Rosinski talk about envisioning documentation spatially to help users’ navigate and find their destination. They give the example of knowing user context when searching for “broccoli” in order to return the best results. There is no question that findability is hugely important in how customers locate and use our documentation, and search engine optimization (SEO) has become a big business. It doesn’t matter what we write if the right audience can’t find it at the right time.
Interestingly, I saw this user-context-based search engine patent filed by Google in 2006 (published in 2013). They discuss the known limitations of search engines and their invention to return search results by categorizing the information based on external context clues. The example that they give is figuring out that a given web site is an encyclopedia based on the surrounding words, and then using information about the user to determine whether they are looking for an encyclopedia.
I think having more context-aware searches would be a boon to technical communication and continue to accelerate our path from content creators to content managers, who look beyond the sentence level to strategic documentation processes.
The second piece of findability is not just locating the right document, but then navigating within it. The Wired article “Findability Will Make or Break Your Online Business” talks about both halves in the context of marketing your business, but I think the same is true for helping readers through technical documentation. The tips on providing user-relevant content and appropriate links (as well as the astounding statistic that 30% of visitors use site search) are certainly relevant to how we create and envision documentation.
Salvo and Rosinksi make a closely related point about using genre conventions and creating a document environment that orients the audience and primes them for a response. By using signposts and making it clear what kind of document they are reading, we can set expectations so the audience knows what to look for and how to respond.
The diagram below actually comes from a SEO company, but the accompanying article “Are You Marketing to Search Engines or to People?” makes a surprisingly counter-serving claim that the best strategy to getting read online isn’t just tricking search engines but creating high-quality content. Documentation that is designed for the audience and understands their needs is more effective in boosting overall findability of both the website itself and particular information within it.
In “Shaped and Shaping Tools,” Dave Clark also addresses genre theory and how we can create standards and templates that help users know what to find. Although perhaps not as obvious as a wedding invitation, what are other ways that we can be using signposts and ambience tools to define the genre of each document and subconsciously cue the audience on what to look for and where to find it?
Salvo and Rosinski quote Johnson-Eilola as saying “the map has started to replace the story as our fundamental way of knowing.” In light of human history, that seems a shocking thing to say, but I do see it being borne out, at least to some degree, as the amount of information grows exponentially and the challenge of navigating it becomes more important. I still fancy myself as a writer about a cartographer, but managing documentation for findability is an increasingly key part of the role.
“Are You Marketing to Search Engines or to People?” KER Communications. 29 June 2010. Accessed 30 Sept 2016. https://kercommunications.com/seo/marketing-search-engines-people/
Hendron, Michael. “Findability Will Make or Break Your Online Business.” Wired. Accessed 30 Sept 2016. https://www.wired.com/insights/2014/02/findability-will-make-break-online-business/
Every once in a while, I open a product I have just bought, and feel a little nostalgic for the days of paper manuals. I guess there’s some comfort in knowing that I can seek out instructions regardless of whether I am online. The truth is, when a question does arise, it is second-nature to sit down and search the internet. And, honestly, when am I offline anyways?
I do remember the days when online help wasn’t so easy to come by. If a manual did not have an answer I needed or I didn’t understand it, I was stuck with the time-consuming tasks of doing my own research. Other times, I would come across mistakes in the instructions or information that became outdated after a software update occurred.
So while I think I “miss” the days of paper documentation accompanying products, I don’t miss all that they represent. I like that I can search for specific issues quickly. I love that outdated or inaccurate information is usually wiped away. And, it’s super convenient that customer support is often a click away, instead of requiring a call to the customer support line.
Now don’t get me wrong, I still print out a lot of the instructions that I look up in customizable searches. I do this because, in many cases, it is easier for me to follow directions on paper. (It is an annoying personality quirk of mine that costs me untold amounts of money buying ink and paper.) I also find that I often look up the same issue repeatedly. I have certain applications that I use on a regular basis. There is usually a function or two that I only use occasionally, so I find that when that rare occasion comes up, I need a refresher on how to do it.
Along with my printing habit, I like to cut and paste chunks of helpful or interesting information from help sections, and put them into a Microsoft document for future reference. I bookmark a lot of pages too. There is a problem though. This inconsistent data collection makes it very difficult to access the information. I have to search my saved documents which leaves me trying to remember if I saved it on my laptop or desktop? Hard drive or memory drive? If I bookmarked it then I have to search through all the bookmark and Chrome and Internet Explorer. This is assuming that I actually recall saving it in the first place. Often I go look up the same information again, only to notice I already had it, when I go to save it. Sigh.
The idea of being able to customize my own instructional text on a site is an incredibly exciting concept (Spilka, 2010, p.206)! I imagine all those topics that I go back to time and time again at my fingertips. No more haphazard organization of all the information I want to retain. No more wasted time looking for information, only to realize I already have it documented somewhere. Just one site to go back to, the source. Not only would all the information that I need be structured in the way that best meets my needs, but I could also add more information or remove what I no longer need. That would be the ultimate user experience!
Until that becomes widely available, I will continue to appreciate the ways that digital media is enabling writers to provide better and more targeted content. The use of digital media has not lead to a homogenized audience, but has instead given many new opportunities for writers to tap into the specific needs of the reader. They no longer have to make assumptions about the reader’s needs and can instead utilize a variety of user information absorbed from observing the user directly. In many ways, the move to greater use of online documentation, defies the image of the internet widening the distance between people. In this instance, online media allows for a greater personal connection with the audience.
My house, could be run by librarians. I have always had a little bit of insanity when it comes to cataloging information and trying to make it easy for others to access. For instance, once upon a time, all of my household manuals were kept in one location. Trial and error made me realize that this didn’t make sense. The kitchen appliances seemed to have a greater need for me to be able to quickly access the manuals. I moved them all to a special location in my kitchen and the rest of the manuals go in my laundry room.
And, if you don’t think that is particular enough, I have a sitemap. In the event that a family member is watching my child, I don’t want them hopelessly frustrated trying to figure out the dust-vac. I have a “map” of every appliance and the room where someone would need it. It then cross-references where the accessories are for that appliance and where the instructions are. Weird. I know.
When I was younger, I actually thought I may need some sort of intervention because of how specific my brain was in categorizing the information that came into my house. I used to file every article that crossed the threshold. That got to be exhausting. I literally had giant binders for topics. It was a bit OCD. I now realize that I don’t need to retain all information I come across as the internet is able to relocate almost all of it. I have to keep myself away from magazines and let the internet (and the document designers) do what they do best, catalog the information for retrieval.
As I read chapter 4, I was all over it. I have been doing most of it for years, even if I didn’t realize it. My binders of information actually take a lot of work to cross-references. While I know that I will only need some information, like when I’m cleaning or in the kitchen, for instance, I know my parents will access it randomly when watching my child. I make sure that they can find the vacuum manual more readily than I would require it. It is the first manual in my household binder.
This is much like the approach for structuring a website. I know my audience. I know what they need and I know where they will get lost trying to find it.
As a professional in the world of technical communication, I often wonder what my role really means for the organization. When people ask me what I do, I often pause and respond with some generic phrase like, “I decipher geek speak for non-technical people”. But, at times I am in the business of marketing our department to the rest of the organization. At other times, I am compiling “How To Instructions” (when I can get away with it). But I often wonder at what point in time does one cross the line between technical communicator, to support help, or even to technical subject matter experts (SMEs). And this idealism off too many cooks in the kitchen seems to ring true from a technical communication standpoint.
I am always asking questions and trying to drive out more information from technical SMEs. In return I am cornered with negative responses and many people not understanding why I’m asking the questions I am asking. Or, my favorite, telling me that no one actually needs to know that (because technical professionals are so good at putting into human terms what they really need to say. But for me this is where Dicks (2010), identifies that technical communication is developing and changing in a number of different ways (p. 58).
I personally believe it is this change, this evolution that may be causing angst for many newer generation technical communicators. Many organizations have to spread out responsibilities and for some organizations; technical communication is a fairly new commodity (especially if they are not delivering some type of technological solution to the consumer world). In the case at my organization, internal technical communication is fairly new and while our primary product is food related, technology is still at the core of our business functions.
I particularly find the following graphic interesting as well when it comes to this concept around both the change that technical communication is unfolding within organizations today and the correlation with “too many cooks in the kitchen”.
This graphic is based on products by LearnMax (2015), a company who specializes in technology training. But for me it is the categories that truly resonate with the different areas of technical communication that I see quite often.
As technical communicators we need to have a baseline knowledge of what we are writing/communicating about. Unfortunately we cannot always trust the SMEs to know what we need and why we need. It’s this type of information that I believe drives technical communication. Dicks (2010) further states, “reshaping [our] status will involve learning technologies and methodologies such as single sourcing and information, content, and knowledge management, and then optimizing information development of multiple formats and media” (pg. 55).
- This statement not only aligns with the knowledge management aspect, but also with regard to the training aspect.
- Optimizing our information for multiple formats hones in on this idea of enterprise mobile and writing for mobile device – not just shrinking our information to fit on mobile devices
- We are also there for the customer – whether it is for an internal customer or an external customer.
Ultimately this all aligns with content development, as shown in the graphic above. It should be our goal to customize our content not only for formats and media – but for our audience. Dicks (2010) calls out the value of our role in the following four categories: “cost reduction, cost avoidance, revenue enhancement, intangible contributions” (p. 61). But I bring us back to my original example in my own situation – of too many cooks in the kitchen and refining the role of technical communication within organizations.
For example, the Information Technology Help Desk was at one point responsible for preparing our department intranet pages. The content, design, and layout was all brutal. In an effort to formalize this channel as a communication tool, I focused heavily on design and updating the pages so they seemed more accessible and inviting to staff. Unfortunately, I would say that this idea / change in ownership of job duties has been a constant struggle. At one point this group never wanted to give anything up, and yet at time if it’s not perfect it is used as an excuse to pass the buck off onto someone else.
So while we can theoretically lay out for management on how technical communication can provide value to the organization, how do we show value to our colleagues who might be more concerned that we are stepping on their toes?
Dicks, S. (2010). Digital Literacy for Technical Communication. In R. Spilka (Ed.), The Effects of Digital Literacy on the Nature of Technical Communication Work, (pp. 51-81). New York: Taylor & Francis.
William Hart-Davidson defines a content management system (CMS) as a “set of practices for handling information, including how it is created, stored, retrieved, formatted, and styled for delivery” (pg. 130). Basically, a CMS sits on top of your content and assists with the following functions:
- Topic management: searchable, reusable content
- Single-source publishing
- Translation/localization workflow
- Collaborative development and version control
- Central output format management
Furthermore, Davidson claims that a best practice of content management includes the
“Need to separate content from presentation (pg. 130).”
But just how difficult is it to separate information from presentation and design?
In my experience, it is very difficult. While it is relatively easy to use the same chunks of content (e.g., single XML files) in multiple output formats, it is not easy to customize the design, format, and style of an information product. Let me explain.
We are currently implementing SDL LiveContent as our CMS. It is very expensive, and due to budget restrictions, my manager went with the basic, out-of-box implementation. In addition, we are required to provide two types of output—PDF and HTML—for every major software release. To create PDF output, we must develop stylesheets to transform our XML to XSL-FO. XSL defines the presentation of XML objects and properties that specify the page format, page size, font size, and paragraph/table/heading/list styles. However, since we went with the basic SDL LiveContent implementation, the difficult, time-consuming task of developing stylesheets for XML to XSL-FO transformation must be done by ourselves. (SDL LiveContent offers services to create the stylesheets, but it is very expensive.)
If we don’t develop stylesheets, we will have little control over the presentation (also referred as “signposting” in chapter 2) of our content. This is unacceptable to my manager, as she expects all of our content to continue to have our professional, company-branded formatting.
If this wasn’t complicated enough, SDL LiveContent recommends a different professional formatting solution from the one that we currently use (and have already spent a lot of time customizing that stylesheet). We all agree that we do not need to have two or three publishing tools to generate a PDF or HTML. We also don’t want to have a complicated, manual workflow process that takes the content from our CMS, generates output (PDF and/or HTML), and then stores it back in the CMS. We don’t have someone on our team who can write scripts to do that and there isn’t a bridge to connect the CMS with our current publishing tool.
Ideally, we want to have our content stored in one repository, and from there, we want to be able to generate output on an ad hoc, as needed basis. We want to click a button—have all the magic happen—and then view the PDF that has a beautiful, professional layout. How we get there is my responsibility over the next few months, but I’m convinced that we will have to ditch our current publishing tool and will have to develop brand new stylesheets.
I like the definition of Content Management that Spilka provides in Chapter 5. Content Management is a set of practices for the handling of information, including how it is created, stored, retrieved, formatted and styled for delivery. It usually has the following four goals: Distribute tasks and responsibilities among members, Author and store content that enable multiple-audience adaptation, Author and store content to permit multiple output and Author and store content that allow for reuse by multiple organizations. Spilka also recommends creating CM as a separate discipline and teach to other technical communicators (Spilka, 2010, pgs 130-131). This definition really is what I do on a daily basis in my current position of QA Specialist, who is also responsible for the majority of customer educational resources for our Home Care product line.
Where I work currently, we use a few different content management systems, most of which were created by in-house staff for our use. The one that looks the most like this definition is our SIETE product. This is the product that we use to track the tasks being completed by the developers, that guide our release notes and user guides, as well as our Knowledge Base which houses the release notes, user guides and other customer-facing educational resources. I was not included in any of the design aspects of this product, it does work nicely for our customers.
The image above is an example of our customer facing portion of SIETE. This is accessed through the application and the content visible on the right-hand side is content specific based on the page the accessed the Help from. In addition, there are additional materials that the user may find useful based on this page. It would include FAQs, User Guide Pages and Videos that were created. This can be updated by our staff immediately if issus or corrections need to be made. This page really encompasses goals 2, 3, and 4. It allows for multiple audience adaptation, permit multiple outputs (html, videos) and reuse within and across organizations.
According to Chapter 4, we, as technical communicators, organize the written communication for future use (Spilka, 2010, pg 123). This SIETE product does assist with this. The search feature within the Customer Facing Knowledge Base will search content and tags that are added to each item. At this time tags need to be manually managed on each task, but helps with searching when the customer may not know the correct term. We can add additional terms that customer might use, even if it does not match the terminology that we use.
The image above shows that Goal 1 can also be used in our SIETE Application. There is a module called Project that has Projects, Outlines and Tasks. Each task can be assigned to a specific person and it can detail what needs to be done, when it should be done and what other assets are needed to complete the task. Often times I will spend a day or two reviewing the User Guide for changes that need to be made. Simple changes will be made immediately, but longer changes will get a task. Once all tasks are assigned I, or my supervisor, can set due dates, priorities and estimate the time to complete. As time allows, these are updated and immediately available for our customers.
Information design and content management are two terms that I knew existed, but they never would have crossed my mind. Technical communicators write and create their documents, but must also design the way they distribute information and manage what they write. Most people only consider the writing part of a technical communicator’s job, but these are tasks in which technical communicators have always engaged. Before the Web grew in popularity, technical communicators kept track and managed their writing in hard copy formats. However, with the enormous increase of documents being created and distributed online, somebody must be responsible for maintaining it: “Search and retrievability – or findability – as well as navigability become increasingly important as the information age produces more documents than ever before” (Salvo & Rosinski, p. 103). A document is useless if the user cannot navigate it or cannot properly access it. I imagine a digital filing cabinet and a technical communicator working diligently to keep it organized. I have created a visual to aid with my giant digital filing cabinet analogy.
I took a stab at defining the two terms:
- Information design – creating or establishing a text using a set of principles to improve the readability of a document
- Content management – maintaining the usability and searchability of a document so that it can be accessed by users
So, in terms of information design, technical communicators “[design] information in written documents so that those who put ideas to work can access content when needed” (Salvo & Rosinski, p. 105). With the increase of electronic documents, it is important that technical communicators consider the format of their document. If they want their users to be able to open up an electronic file and type their information directly into the file, they must design it in such a way. Design in a key element in helping readers understand the document. Also, technical communicators are “charged not merely with the activity of writing, but also with […] looking after the information assets of the organization” (p. 128). Increasingly, technical communicators are responsible for keeping the information they write organized so users can locate it. If a graphic designer creates a company logo, it will fall on the technical communicator to keep a digital copy of the company’s logo managed so that the marketing department, and any other departments, can locate it for their work.
Technical communicators use various systems for designing information and for maintaining documents. InfoDesign is a blog that provides technical communicators with current information and communication strategies. Technical communicators can use the tags to search for posts about a relevant topic. Companies have many options in terms of managing their content. CMS Matrix allows users to sort through a list of 1,200 content management systems and compare selected systems. Top Ten Reviews contained numerical data comparing the most popular content management systems.
So does this giant digital filing cabinet create more work for a technical communicator? I don’t think so, unless the technical communicator is not properly designing and managing his content. I think properly designing information and managing it correctly can actually help a technical communicator be more productive in the long run.
This week’s readings discussed at length content management and information design. With the rapid changes and growth in the use of digital technologies, both of these areas have changed drastically. These changes include:
- How we store information (paper vs electronic)
- How we design information (memo vs email vs social media messages)
- How we collect information ( paper surveys or comment cards vs tracking IP addresses)
- How we interact with users of the information (one-way transaction vs synchronous engagement)
Going back to my internship during college in the early 2000s, I realize now that I was involved with an early form of capturing data electronically. I worked for a global heater company that had endless numbers of user manuals for all its brands of heaters, even some they no longer made, but still serviced. One of my first projects as an intern was to scan the manuals into PDF form and save them to a folder on the shared server. It was tedious work, but, looking back, I can see how beneficial it was for them to have me do this. At the very least, they wouldn’t lose those user manuals if the building started on fire!
Today, I work for a company that operates a specialty retail pharmacy that is required to keep paper records for seven years. Despite the 10+ years that have gone by, it feels like a step backwards in the world of enterprise IT. However, with all the changes in healthcare (most notably EMR/EHR implementation at hospitals and clinics), I wonder how long it will be until other healthcare facilities (like a pharmacy or nursing home) will be required to go digital with their records as well.
It’s not just the pharmacy that can be dubbed a tree killer at our company. Our #1 marketing activity to bring in new business is direct mailings. Most recently was a postcard mailing to over 1000 allergists on the East Coast. The postcard was to advertise a webinar so the information delivery will be online and paperless, but any follow-ups to those that participate will very likely involve mailing paper documents, including a 100+ page manual that outlines the specific allergy modality that we promote. Is this a waste of paper? I think you have to weigh the pros and cons. This manual is not something that we mass distribute; it only gets sent to those truly interested in our services. If we were to allow access to it online, would we be able to prevent its dissemination to those we don’t want to have it, like competitors?
I am happy to report that our company has made at least a few efforts to reduce the amount of paper we use – the customer portal that I mentioned in last week’s post is one of them. One of our goals for implementing this website was to give clients access to a number of the patient education materials that we normally print and mail to them. We actually just had to review which ones we needed to reprint as our inventory was getting low on a number of them. We ended up deciding not to reprint a number of them. We want customers to get them online instead.
This online portal acts as more than just a way to reduce paper cost – it also acts as a type of content management system as it gives us a place to organize, store and communally update a large amount of information for clients, but it also allows us to track usage and activities on the admin side, which I think this week’s readings showed us is just as important as the storage and organization of the content. From Moore (2011), one step he recommended for B2B enterprises (like the one I work for), is to “mine community content to extract insights to enhance the business” (p. 7). With our portal site, I can see when users log in and track what areas they are visiting most often. This can be helpful for updates to the site because we can see what people use and like. It’s not as sophisticated as how Google tracks our online footprint, but it works for us.
Speaking of content management, I also work with an online customer relationship management system called Salesforce CRM, which some of you may be familiar with. Salesforce is a fully customizable, on-demand program that I have been able to mold into what the company needs to track sales and customer growth. It truly embodies the definition of content management. It gives us a turnkey solution for “handling information, including how it is created, stored, retrieved, formatted, and styled for delivery” (Hart-Davidson, 2010, p. 130).
From a generic framework, I added custom fields, inserted formulas and stages to predict closes on new sales, built new pages and sections, and created reports. We now use Salesforce to not only record all basic account information, but also as a reminder system to stay on top of daily, weekly and monthly activities. It also helps us monitor marketing campaigns and the progress of specific growth strategies. Additionally, it has document storage capabilities and allows us to build email and letter templates to create a uniform method of communication delivery. Finally, we have been able to build both basic and in-depth reports to help with sales analysis and communications. For example, we can run reports to see how many leads are in the sales pipeline, or create mailing lists to customers that have signed up to receive our quarterly e-newsletters.
Essentially, this program allows us to mine data on current and prospective customers, stay on top of our communications to these audiences, and plan future communications, whether it is a mailing, email blast or marketing push. It is the backbone of the account management, sales and marketing departments.
Like one of the CIOs said in the Moore (2011) article, “We are grappling with this” (p. 6). In some areas, my company has transitioned into the new era of enterprise IT quite well, but, in others, we are still figuring it out. I long for the company to be more technologically adept, but, in the grand scheme of things, I think we’ve made a lot of great strides, especially considering the small size of the corporation. It also made me feel better to read how many companies are struggling with this transition, so we are not alone. Overall, I think that as long as we keep trying to move in the right direction, we’ll be okay.