[Podcast] Uncovering and communicating the value of your tech comm teams' work, with Keren Brown
Listen here:
Note: This podcast was sponsored by Zoomin Software.
Topics covered in the podcast
Here are some of the topics we cover in the podcast:
- The impact of recent tech industry layoffs on technical writers and the importance of demonstrating value to maintain job security
- Specific strategies for aligning documentation work with the company’s high-priority initiatives, such as increasing NPS, reducing support costs, and generating leads
- The importance of identifying key stakeholders and collaborating with other departments to understand company goals and tie documentation to those objectives
- Using analytics and data, such as website traffic, user engagement, and support case deflection, to quantify the value of technical documentation
- Creating compelling value realization reports and presenting them at strategic meetings and events to make technical writing work visible to executive leaders
- Leveraging support case data and user feedback to identify pain points and problems that documentation can solve, and using this information to guide content creation
- The evolving role of technical writers in the age of AI, and the importance of developing skills such as prompt engineering, content structuring, and AI-driven content optimization
- Evaluating the ROI of proprietary documentation platforms versus open source tools based on factors such as efficiency, scalability, and integration with AI technologies
- Reassessing the impact of translation costs on documentation strategies in light of AI-powered translation tools, and using analytics to make data-driven decisions about localization investments
- Keren’s experience helping companies realize the value of technical content through Zoomin Software’s value consulting services and benchmark reports
Keren’s contact info
Resources mentioned
Transcript
Here’s a transcript of the podcast. (Note that the grammar has been cleaned up a bit by AI to make it more readable.)
Tom: Hi, you’re listening to another podcast from I’d Rather Be Writing.com. My name is Tom Johnson. Today I am talking with Keren Brown of Zoomin Software, and we’re going to talk about value and tech comm, and how we can provide more value to our employers in our role. Keren, before we jump into things, can you just tell listeners a little bit about yourself and your role at Zoomin Software?
Keren: Sure, absolutely. Thank you so much, Tom, for having me today. My official title is the VP of Marketing and Value. My team is responsible for everything related to value creation and realization for our customers, but also every company in the world that is looking to either make an investment in their content or already did invest in their content. They want to see what is the ROI of this investment and how they can actually move from being perceived as a cost center, whether it’s the Docs team and technical writers, to a genuine revenue growth engine for their companies. We love it.
Tom: Well, this taps into an age-old conversation about the value of a tech writing role at a company. It’s one that I’ve researched previously, and there’s been an ongoing conversation about this topic for the last twenty years, but it’s really come into the spotlight lately with the recent layoffs in the tech industry. If you go to a site like Layoffs.fyi, you’ll see that in 2023, there have been thousands of layoffs. The exact numbers are kind of staggering.
Keren: Oh yeah.
Tom: And it’s almost become normalized in the industry. I think a lot of tech writers especially are on edge that they could easily be squeezed out if they’re not perceived as contributing value to the bottom line and to growth. So let’s just jump into the big question: How do you establish yourself as a highly valuable resource, especially in comparison to engineers and other roles, as a tech writer in your company?
Keren: It’s a great question. A lot of companies during the past years have been asked to either do the same with less or even do more with less. Technical writers have obviously been impacted by the economic situation, and so I would say the pressure or the compelling event to actually show your value is even more acute.
The main thing is to first identify what are the business goals of your company and see how you can actually start evaluating documentation as it relates to that. For example, if your company is looking to increase its NPS (Net Promoter Score), reduce its support costs, or generate new leads, these are things that we know today, through a methodology that we’ve developed and implemented, how to tie the impact of documentation and technical writers into those core KPIs and goals. We literally take the data that technical writers use every day, like the traffic they have on their documentation portals or the returning users they’re seeing coming back to consume technical content, and even cases that were either avoidable or deflected because users were able to read your content and self-serve without contacting your call center. We know how to tap into that kind of data to build a full value realization case for the writers.
This isn’t even going into how critical technical writers are today with the introduction of AI in technical content, but we can talk about that later. That’s positioning technical writers in a whole new strategic way to their companies because every company in the world right now is looking into AI and GPT. It all starts with knowledge and the content that you have, so we’re seeing a completely new balance of power between writers and developers, for example. But that’s a different discussion, maybe.
Tom: So, you mentioned identifying your company’s goals, such as NPS (Net Promoter Score). I feel like I’ve seen this often at companies I’ve worked in. There’s like a general satisfaction rating that’s sent out to users, customers, and partners. It’s kind of a vague, general satisfaction score, and usually companies want to improve that, right? It would be weird if a company didn’t want to improve how satisfied their users and partners are. That’s definitely a common business goal. How do technical writers find out what these high-priority business goals are for a company? Is there a good way to figure this out?
Keren: This is such a good question, Tom. I think one of the first things that come up when we have these value conversations with technical writers is: (a) How would I know? and (b) How would I actually get the data that I don’t have at my fingertips? For example, the NPS score or the self-service rate. Usually, these are performance indicators that lie either in some other business unit, within your support organization, or maybe your customer success organization.
So one of the first things that we do when we kick off these value conversations is identify together who are the stakeholders we need to bring into this project. You really cannot tie your value to the business goals of the company if you don’t understand what your VP of Support cares about or is being measured on, or what are the quarterly deliverables of your customer success team. What we’ve seen is that the value conversation has become such a wonderful trigger for technical writers to come out of their shell, in a way, and their isolation, and actually start looking and understanding what’s going on with other teams in the company.
Usually, they find out great things. They find out new audiences that are using the content and new audiences that use it to actually meet their own goals, which is great.
Tom: Let’s take this one step further with an example. Let’s say that a company’s goal is to increase its user base by, I don’t know, 10-15% user adoption. How, as a technical writer, can you make the case that documentation is contributing towards this goal? I mean, there’s always this disconnect between docs and the actual goals that has been very difficult for tech writers to grasp or to make the connection between.
Keren: Let me give you a few examples here. First, we know from very clear data that today, potential customers or even existing paying customers refer to technical content and product content as the source of information before making a purchase, more than they go to other places like your company’s marketing site or even peer-to-peer forums.
We know that the decision to make a purchase or maybe to buy more of your product is heavily reliant on the kind of technical content you have and whether the users see that what you have is what they need from a functionality and capability perspective. This is throughout the user journey. If a user is just browsing around for a solution, if you have better content than your competitor, they’re most likely to come back to you. If they’re on the verge of just onboarding, they will use technical content to onboard, and so on and so forth.
What we are seeing is that documentation portals, which is the home for technical writers, are actually becoming the number one traffic for a company’s users. If you know how to measure that and you can actually see that linear growth in traffic, and you know that part of this traffic is people making a decision to buy your product, this is definitely something that you want to surface up to your leaders and justifies an investment in making your content better. That’s just one example.
Another example, which is another value metric that we often measure, is returning users. What we’ve seen is that when people visit your documentation often, and even to be more specific, more than twice in the previous 30 days, they’re twice as likely to actually become a paying customer. If you know how to measure this number of returning users to your documentation portal, you can pretty easily do the math about what is the potential business growth that can come from these returning users. We’ve done this value realization with a few companies and we’ve seen some really amazing results.
Maybe the last example that I can give you, because we know how traffic is now shifting from people visiting the .com to documentation sites or portals, is a best practice that we recommend. Actually put a “Book a Demo” option in your documentation portal, and you can literally track new leads coming specifically from technical content. This can go up to a thousand qualified marketing leads per month. It’s enormous and amazing.
Tom: Thank you! Those are really concrete strategies there. I can see how having access to the analytics is essential and the foundation for any kind of argument that you would make about value. I really like the first example that you gave about how documentation is used for prospective customers. I see that a ton in my role. I’m asked to give access to documentation for a certain user that’s looking into the product and so on. I’m thinking I should be tracking this and highlighting this and making the case for this.
This leads to another question: Let’s say that you have gathered this data and you’ve got information that says, “Hey, we’ve got a ton of leads coming from the documentation. We’re seeing returning users at a high clip here, and we’ve got all these prospective users that are using documentation to evaluate our product before they even buy it.” How do you communicate that upwards to executive leaders? I mean, usually I’ve seen people do some kind of newsletter email campaign that has a large list that includes VPs or other stakeholders. But in my space, there are so many newsletters or so many of these email reports, it’s really hard to get traction. I’ve taken up multiple efforts to do documentation newsletters and they just get very little feedback. So how do you communicate all this value upward?
Keren: Great question. First of all, I think there’s a lot to say on behalf of reports. When we work with our customers, we are designing a beautiful, branded value realization. It’s not really a newsletter, it’s a value realization card, as we call it, and it has very specific KPIs. I think senior leaders and executives really want to look at numbers, and we try to emphasize that and send it as something that they will be proud to show, with very clear results. But that’s still sending things out.
The more important thing is that the majority of technical writers and docs leaders that I spoke with, they do have yearly business reviews or conferences that they’re presenting at, or even marketing summits. There are a lot of compelling events that are really good opportunities and great stages for you to actually show something like a value card. We’ve seen these get a lot of attention from company leaders.
So I would recommend first using that as kind of the meat for your next quarterly business review, or see what is the next event, conference, or summit that you can feed your leaders with this great content. I think numbers speak, and so we’ve seen this being adopted by CEOs, CFOs, CROs, and one of the things that we saw that is actually getting executive attention is when you’re able to show your leaders how your company is comparing against other companies. There’s always the question, “Okay, I saw the data, but are we doing well? Is this good? What are my competitors doing? What are other companies like ours doing?”
So another great tool that we released recently is the Technical Content Benchmark Report. This is a very robust document where we took about 30 different content KPIs, from session duration, traffic, engagement, a lot of KPIs, and we basically analyzed what good looks like or what is the benchmark across the industry. We had over 60 million content sessions analyzed in this report. Every company that is doing their own value realization can also work with us to see how they’re doing against the industry, against companies similar to them, against companies that are their competitors. I think this kind of information is very useful and interesting to leaders.
Tom: Yeah, I featured a post about the Technical Content Benchmark a while back. I didn’t know about this and I thought this is great, to have an actual baseline against which you can say, “Hey, this time on page corresponds with the benchmark,” or “These are actually good numbers.” Trying to interpret your analytics is really hard. I know that usually tech comm groups get together every now and then to make goals, and they usually want to quantify them with some kind of improvements to their analytics. It’s always this shot in the dark, like “Oh, well we want to have more traffic to this page,” but the user base is different for this product than that product, and so it’s like they don’t really match anyway.
All right, I want to go down another question and theme. You talked about establishing value from pre-purchase scenarios, as well as returning users, gathering leads, and so on. But there’s another value that you briefly mentioned about documentation providing resolutions for support cases or somehow tying in with that.
Keren: Yeah, yeah.
Tom: That angle — and this is one aspect that I think a lot of tech writers can probe. You can look and see how many support cases referenced documentation in the thread or somehow documentation played a role. Can you speak a little bit about that? How do tech writers go about probing the impact of docs in support cases?
Keren: Yeah, absolutely. So first of all, I would differentiate between three use cases of that connection between documentation and support:
- Cases resolved with documentation
- Cases deflected
- Agent efficiency, which means that agents have used documentation in order to resolve a support ticket.
If you think about cases resolved with documentation, this is where you actually need to understand a little bit how your support team is classifying the different support tickets. What we’ve seen is that a typical classification will be feature request, reporting a bug, or a “how-to” question — like “How do I do this?” or “How do I do that?” Usually, the questions or tickets that are tagged as “how-tos” can easily be resolved with documentation. This is exactly the bucket that you want to tap into and see what’s happening with this. By the way, further investigation can lead you, for example, to develop additional content that isn’t available when you investigate what exactly the ticket was about. But let’s put that aside.
So this is what we’re talking about — cases that have already been opened, but documentation was the answer to the question, to the ticket. The second is cases deflected. Now, when we talk about case deflection, that’s a little bit trickier to measure because what we’re measuring here is that a user had an intent to open a ticket. They may have opened the ticket, started typing the subject line or whatever, but through — in our case, we have a case deflection widget which actually surfaces, at that point, relevant documentation based on the subject line and the keywords that you started typing. It’s kind of a last-mile help. If you actually found what you were looking for, you didn’t click that submit button in the ticket, and so that case was deflected. It never happened.
Obviously, you need the technology or the widget to help you track that kind of journey, but the business impact of cases deflected is enormous because you’re not just saving money for your support organization. You just made a very happy customer because they didn’t need to go through, let’s face it, most customers want to self-serve rather than contact support.
And the third thing we talked about is agent efficiency. We know that cases that agents have either attached content to or resolved through documentation cost significantly less than cases where they needed to have a phone conversation with the customer or start an email thread and so on and so forth. When support agents resolve cases with documentation, and we know what the average cost per ticket is if it was resolved with documentation versus if a phone call happened, then we can actually measure the impact of using more documentation with support agents. This is again another methodology that we’ve implemented with a few of our customers.
Tom: I can see how having a system that allows you to calculate automatically the case deflection that surfaces content in the same sessions that agents are working, or in the same session where a user is trying to ask for help, can really be powerful. Having a unified portal with all of this coming together seems highly valuable.
But even in my case, we don’t really have our support system tied in with our documentation. Many companies have an issue tracker that has a ton of issues that are just coming in from various sources. The more public your docs are, the more you see these issues. But even with a small number of users, there still can be an overwhelming number of issues to sort through.
This got me thinking — is this maybe an area where AI can play a role in summarizing issues, going through long threads, parsing them, and saying “Yeah, this was the issue. This was the resolution. Documentation did play a role,” or “Documentation did not play a role,” or “This was unrelated to documentation. It was just a product bug.” How do you see AI playing a role in issue tracking analysis?
Keren: It’s a huge topic, and I think what we’re seeing is AI coming into our ecosystem, into technical writing, in various ways. First of all, even before addressing classification of issues and doing the analytics on that, implementing AI and GPT capabilities in your technical content has already — we already saw initial numbers and results that by doing this, you’re going to increase self-service rate.
First of all, like you said, Tom, we’re talking about AI capabilities to summarize long topic pages and give very clear, precise, fast answers to users. People use GPT now in their day-to-day, they’re used to that kind of experience. By the way, in our content benchmark report, we are seeing a trend of users spending less and less time reading long documents. It’s all about fast, accurate answers, and this is where AI can definitely come into play. That’s one thing.
And yeah, I think service applications are the main place where AI is being implemented, whether it’s for agent efficiency, for agents to use AI to literally make content recommendations to customers opening a ticket or having an issue, summarizing the thread — a lot of use cases where AI comes into play. Again, we are seeing this. We’ve seen companies using AI in their service. One company has seen a 95% decrease in the time that it takes to generate a response by an agent by using AI, for example. So happy agents, happy customers. It’s a huge field right now with amazing opportunities, both for support and documentation.
Tom: This leads us kind of to the biggest question of tech writers and tech comm today. Let’s say that a company develops and rolls out an AI agent, like their own AI-powered chat. How do tech writers establish the connection between the documentation they’re writing and producing and the intelligence of that AI chatbot? I feel like these chatbots need a body of accurate, relevant information in order to have good output. But I don’t know if companies make the connection between tech writers and the documentation we produce and the quality of the chatbot. How do you establish that link?
Keren: Yeah, well, it’s very clear that any AI application, any model, any LLM (large language model) is only going to be as good as the content that it has. And when we say “the content that it has,” we’re talking about breadth and depth. First of all, we need to make sure that there is enough content to basically have AI be able to ground any kind of query into that. But the content needs to be quality content, and this is exactly where technical writers come into place.
Enterprise knowledge, product answers, API guides, whatever it is that you’re working on, whatever content types, different authoring tools — this is what, at the end of the day, compiles your enterprise knowledge. AI models need that level of quality, breadth, and depth in order to function, in order to basically retrieve an answer, summarize a topic, or whatever it is that you’re looking to do with AI or correspond in a chatbot.
You’ll be able to very easily see — and by the way, we had companies, for example, that ran hackathons where they tested chatbots with or without unifying knowledge into a single place. You see it immediately. Either you’re getting a fuzzy response on the verge of hallucination, or the AI is telling you, “I’m sorry, but I could not find an answer,” or it’s redirecting you somewhere else. And you don’t want to redirect customers.
But when you have unified knowledge and technical writers are part of the game, and you’re actually connecting the models to your documentation portal, the results are incredible. We’re seeing over 80% in accuracy and coverage with that kind of a use case. So it’s a very clear case of the impact that technical writers have.
Tom: I know that personally, as just a user, when I use AI, if I’m trying to find an answer to a question for a tool that I’m using, I will often gather up all of that tool’s documentation. This could be internal docs or something that I didn’t work on, and I’ll just plug it into the chat session and then start asking questions. I probably save a lot of time not having to read through all that documentation to try to find the answer, or maybe it’s written really poorly, maybe it’s an engineering-written kind of doc. The results are great. I know this is kind of a manual version of RAG (Retrieval-Augmented Generation) where I’m augmenting the AI’s intelligence with all this documentation that I’m feeding it. I really hope that people who are in charge of AI, who are rolling it out, understand that connection and value, and see that, hey, this is so much better when we have a large body of good docs versus when we don’t.
Keren: It’s one other aspect that is very important to mention. Good documentation also means secure documentation. As writers, we know that we have public content or gated content, and we have permissions. Users are able to see maybe pieces of content, and other users are forbidden from seeing these pieces of content. When you start working with AI, you have to make sure that the same security layers that you have in your docs portal apply to AI. You don’t want to create that kind of exposure.
So technical writers, through the work that they’re doing, are also helping to make sure that the AI layer is as secure as their documentation portal, which is a critical aspect to all companies today.
Tom: That is an important point worth noting and bringing up here. Let’s say that you have a complex doc set with like 20 different permissions based on features users have purchased versus haven’t. How do you get your AI to give you that experience of knowledge based on what the user should be able to know, based on their permissions? That seems like an impossible sort of scenario. Or is it just something that you can only do in real-time by having the AI search certain pages that it can access for the session? How do you handle that?
Keren: Without going into the nitty-gritty of the technology here, it’s definitely doable. Basically, the way that we work is through what we call content role groups. You have a group of users that have certain permissions to see certain content, and they’re not allowed to see other pieces of content, whether it’s you have partners, employees, and customers, or you have customers that have purchased product A, product B, and so on and so forth.
What’s happening under the hood is that if a user is asking, let’s say they’re asking a GPT question on your documentation portal, if they don’t have access to this content based on the content role groups that the administrator, the technical writer, has set up, then this content won’t be sent to GPT, to AI. And you will get, “I’m sorry, I could not provide an answer to this question.”
So our technology basically takes the same permissions and literally embeds them into the process of sending content to AI. That’s basically the way that you handle this, and this is the same for public and gated content. Some companies have content that is completely gated, so these specific topic pages won’t be sent to the model to retrieve an answer.
It’s also very important to say that we, specifically Zoomin and our GPT, we’ve opted out of any option for any public AI models, like OpenAI, to train their own models based on our customer content. We’re taking robust security steps to make sure that permissions are in place, gated content is secured, PII (personally identifiable information) is masked away, and other things. But I don’t want to get too technical right now. But it’s definitely something that is on everybody’s mind.
Tom: Yeah, and this brings another question I wanted to talk about, and that’s tech writer skill sets. You’re talking about configuring a complex permission system here, which is outside the bounds of writing docs. It’s part of documentation, right? Because you’re feeding and configuring what knowledge an AI has. The question that this leads to is: What skill set should technical writers really emphasize?
We’ve been hearing for years that writing itself has been commoditized. It can be outsourced. It’s not really a huge selling point. And so there are lots of other emphases that tech writers do. Maybe you become a tools expert. Maybe you become an AI expert. Maybe you become an API design expert. But people tend to try to move away from just celebrating the writing aspect of their role. What do you think tech writers should do to really establish the most value for their role?
Keren: So it’s interesting that you asked. A few weeks ago, we published a blog titled “Will AI Steal My Job?” And basically, bottom line, no, it’s not going to happen. But here’s what we’re seeing.
First of all, yes, AI has made it easier for different people in the company, not just technical writers, to write content. But it’s only the technical writers that actually have the structure, the guidelines, the brand language, the key way in order to take this, I would say, virgin content and actually make it content that you will then publish to your documentation site. So it’s still very critical that the profession of technical writer will be used, even if it’s easier to have more people, subject matter experts or so on, write content. So that’s one thing.
The second is a very interesting skill that we’re seeing more and more AI technical writers adopting, which is prompt engineering. Because in order for you to work with AI, you actually need to know what to ask for. This can be a full university course, but prompt engineering is fascinating. And as technical writers, if we want to use AI in the most efficient way and in a way that actually matches our content writing guidelines, we need to be skilled with prompt engineering, which is a fascinating territory. So I think that’s another thing.
And again, everything that has to do with getting your content and your knowledge ready for AI, it’s on technical writers. Whether it’s starting to think about microcontent versus long topic pages, that’s one example. Synonyms, for example. It could be that your users are going to ask a question using some other words, so you’ve got to make sure your synonyms are in place. There are other aspects in making sure that the content is AI-ready that only technical writers right now are and should lead in their companies.
Tom: Well, that’s a reassuring answer for sure. I love prompt engineering. I actually have a whole prompt engineering study group that I lead at my company with lots of different writers from different groups. And I find it just pure fun to try to figure out how to apply AI to a certain scenario.
For example, the scenario that I’m trying to figure out in my head now is I’ve got two different APIs with a lot of similar fields, and I want to make sure that the documentation across both APIs is consistent. How do I bring up both API field definitions side by side and then figure out which one’s better and so on? This is hundreds of different fields to do this, and I’m thinking this is going to be a great scenario for AI to surface all this up.
I love trying to design, well, how would the prompt go? What would this be? I do feel like it’s a valuable skill, and it leads to the ability to create better content more quickly and efficiently most of the time.
Let me ask another question that I’ve been wondering about in terms of value. It seems like in the past, a lot of the value arguments for tech writers were related to translation. Translation is a huge cost center, and so tech writers would say, “Hey, look, I’ve single-sourced this content now. There’s only one source that’s being generated into these 10 different languages and it’s saved us x amount of money,” and so on. This has been the driver for structured content adoption and XML systems.
But now I kind of get the impression that translation is just all being handled by AI. I mean, it’s already been machine translated for many years before, but even now, I was writing — I don’t work a lot with translation — but I was responding to a friend of mine in Spanish and I just plugged my whole email into Gemini and had it translate into Spanish, and it looked great.
So I’m just kind of wondering, is translation still a cost driver? Is this something that, when we think about our value and we make these value arguments, is translation still something to consider?
Keren: Well, I guess it depends on how far you went with implementing AI tools for translation, but it is a big thing. Even if we put aside AI and how we can use AI to reduce the costs here, the investment in translation, and this goes back to analytics, should be data-driven.
For example, if in our analytics we’re able to show our customers where users come from and where their content readers are coming from, and if you are seeing that a lot of your users, for example, are coming from Germany or from France or from Israel, you may want to consider investing in translation because, again, you want to be where your users are, even from a language perspective.
I think, again, if it’s still a cost center, probably yes. If it can be more efficient with AI, probably yes. If it’s worth the investment, look at the data and make decisions where to invest. Maybe you’re investing in languages and you actually don’t have a lot of readers coming from that geographical location. So the data should actually route your decision. But if you have the data, I think the case for the investment is simpler to make.
Tom: Well, we’ve talked about a lot of different topics related to value. I’m wondering, is there any area or topic that we didn’t cover that you think we should cover?
Keren: No, I think we touched on a lot of things. What is really important for me to convey here and send a message to all technical writers out there is that it can be done. A lot of technical writers that we speak with are not sure where to get the data from and how they can quantify it and how they can measure it and how they can present it. You’re not alone in this journey.
There are a lot of resources that can help you go through this, and it doesn’t need to be — you don’t need to write a Ph.D. You need to really choose 4 or 5 KPIs that are important to your company, work with consultants in the area that can help you put that dollar amount on the value that your documentation have.
I don’t think I’ve ever met a company that wasn’t able to show very clear ROI on documentation. It’s more about opening your mind to a lot of those KPIs that you may not even thought are impacted by documentation. We have so many examples of such correlations that we were able to make with our customers. It’s a very exciting process and it definitely got technical writers that have gone through this process a seat at the table. So go for it.
Tom: Thank you. Yeah, I really like your advice to just focus on like 4 or 5 KPIs rather than trying to tackle this huge swath of analytics. You mentioned technical writers who have gone through this process. What exactly are the services you provide around the value cards of data analytics? Can you just mention that briefly?
Keren: Sure. Zoomin, through our value consultant services, works with companies to basically take them through the 4 steps of creating a full value card.
First of all, identifying the KPIs that they would like to measure. Second, we work with them to collect the data, whether it’s internal data or data coming from the Zoomin benchmark database. Then we use our methodology to quantify and literally put that dollar amount on the data and take the KPI and show the clear ROI in regards to the KPI that we chose.
We also provide you with a fully designed and branded value card, obviously with clear explanations about the process, and you can share it with confidence with your stakeholders. Usually, this is a process that can take between 4 to 6 weeks. We also, throughout this process, speak with the stakeholders that are involved, whether it’s support, customer success, R&D. We’re really here to help you and take you through the entire process together.
Tom: Cool, I actually didn’t realize that you offered that service. I mean, I usually just think of platforms as tool vendors and so on. But the fact that you would help tech writers make the value case like that seems highly worthwhile, especially if you’ve got tools that help facilitate surfacing the analytics that you need to make that value case.
Well, Keren, you have a lot of knowledge about many topics, and we always steer into AI. I love it. It’s like you’ve got a lot of cutting-edge knowledge when it comes to this topic. So that’s very helpful. Thanks again for coming on to this show. If people want to learn more, where should they go?
Keren: You can just go to zoominsoftware.com or reach out to me directly. I’m happy to help anyone who’s looking to learn more about AI, value, or any other topic. My email is [email protected].
Tom: All right, Keren, thanks so much for coming on to this show.
Keren: Thank you for having me.
Note: Some summary content in this post was AI-assisted.
About Tom Johnson
I'm an API technical writer based in the Seattle area. On this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, AI, information architecture, content strategy, writing processes, plain language, tech comm careers, and more. Check out my API documentation course if you're looking for more info about documenting APIs. Or see my posts on AI and AI course section for more on the latest in AI and tech comm.
If you're a technical writer and want to keep on top of the latest trends in the tech comm, be sure to subscribe to email updates below. You can also learn more about me or contact me. Finally, note that the opinions I express on my blog are my own points of view, not that of my employer.