Skip to content

Strategy

Technical knowledge is spread across four teams, and the website needs it in one place

In a medical device company, each team holds part of the knowledge about each product. How to bring that knowledge together without losing where each piece of data came from or who confirms it.

Content auditWeb copywritingContent architecture

4 min read

Engineering has the implant's codes and sizes. Product knows which family it belongs to and which other line it's sold with. Medical Affairs uses a precise name for the procedure, which doesn't always match the one in the brochure. Customer Service knows which catalog distributors ask for every week and which one no longer exists. That product's page on the website needs all four, and none of those people has time to write it.

Gathering information for content at a company like this has little in common with asking a client for copy. Each piece of information has to be found where it is, with a record of who provided it.

One meeting to show the map, one thread per team to do the work

The meeting with all the teams serves one purpose: for each lead to see the site map and understand where what they know is going to live. Products, medical education, events, customer service, the company. That's where relationships come up that save work later, like a document that needs to be both on the product page and in the library, or a faculty member who teaches courses and also needs a profile of their own.

That meeting isn't enough to produce content. At SAI, after the meeting with everyone, we opened a thread for each content area: the company, customer service, medical education, products, and events, each one with the people who had that knowledge rather than the people who held the title. Medical Affairs and Engineering in products; the physicians from Medical Affairs in education. Each thread moved at its own pace without holding up the others, and the company's management was copied on all of them, with visibility and without having to take part in every topic.

After each meeting, each team received a summary, examples to work from, and an open document to set down what it knew in its own words. A fixed questionnaire forces people to translate their knowledge into the agency's format before the agency has understood it.

Every data point with a source, a status, and an owner

What comes in from each team arrives in different formats: a technical PDF from years ago, a congress presentation, an email, an answer given in a meeting. For that to become a product page, each data point needs three tags: where it came from, what its status is (confirmed, pending, under review), and who has to confirm it.

Discrepancies are the most valuable part of discovery. The brochure gives one size and Engineering's spreadsheet another; the trade name appears in two forms; the technique has one name in the video and another in the catalog. Picking one version just to keep moving takes the problem out of sight. The discrepancy is noted next to the data point, with both sources, until the right person resolves it. A to-do written as “check product” leads to another meeting; one that says which product, which data point, and who answers it gets resolved in a single message.

Three of SAI's technical catalogs. Much of the data on each product page came from documents like these, cross-checked against what each team confirmed.

Writing what had never been written

At SAI, very little of the content existed as publishable text. There were technical documents, presentations, and the judgment of the people who worked with each product. We wrote the copy from those sources, with AI assistance to compare materials and spot terms that recurred with variations, and each team validated its own part.

Clinical terminology is the clearest example of why the source matters. Product confirms the trade name. Medical Affairs sets the name of the procedure, and it has to say the same thing on the product page, in the brochure, and in the video. If that's decided and written down once, whoever adds the next product page doesn't have to interpret an old conversation.

Approval is visible in the same place as the data

Engineering fills in a bilingual template for each product. Approved cells are colored green, which separates “I think it's approved” from “it's approved” without searching through email. A single product page can hold confirmed data, pending files, and translations under review, and each one's status is in plain view.

Once the template is complete, the product page is entered as a draft and reviewed in preview, on the actual page. That's where what the spreadsheet hides shows up: a title that doesn't fit on the card, an image of another product, a PDF attached to the wrong one.

That workflow is still running at SAI without us. When a new product comes in, the template already shows where the code goes, who confirms the clinical name, and which document belongs with it.

Services covered in this article

Keep reading

If an article describes what's happening at your company, let's talk.