Why us?
What makes us that good? Our technical expertise and agile skills. We are not only good writers, but also technical experts. Our deep expertise in information architecture can help you design the best single-sourcing documentation solution.
How-to Videos and Screencasts
For a B2B SaaS business, the documentation is the additional line of support that scales infinitely. One how-to video can be served to millions of customers at almost no incremental cost.
In-app User Assistance
Engage your users and help them realize the maximum value from your application by providing in-app user assistance.
Online Help
We design, write and implement online help systems for desktop and Web-enabled software applications. We implement true single-source solutions—so that you can produce all of your information deliverable—print, PDF, HTML, XML, HTML Help, and more—from a single set of source documents.
API Documentation
API documentation is basically a part of the API itself. One without the other is essentially useless. In fact, for such products, developers will often judge the product by your API documentation.
Custom SaaS Help
You have customized your SaaS software implementation, but have you customized the help for your users? We can help create custom in-app content and help.
Custom Salesforce Help
Create your own help for your Salesforce implementation. Integrate it with Salesforce help or turn off Salesforce resources.
Custom Help for SAP
Use SAP Enable Now to create, maintain, and deliver performance support, learning materials, and documentation content easily and natively.
Custom Help for SAP SuccessFactors
Create custom help text to provide additional information about the purpose of a custom field.
Custom Help for Oracle
Modify existing Oracle product help files with your own custom help files or create your own custom help.
Custom help for Microsoft Dynamics 365
Connect custom help site to Dynamics 365. Publish content as HTML, deploy a site and extend the help pane to connect to the Dynamics 365 help.
Custom Help for Freshworks
Create custom help text to provide additional information about the purpose of a custom field.
Custom Help for Servicenow
Provide custom embedded help topics and in-app user assistance for your custom implementation.
Custom help for Workday
Still creating standalone slides and pdf documents to onboard your users to Workday?

Our Technical Writing Process

Our technical writing process ensures that writers work in sync with the development teams and strive to complete their work in the same sprint. (N+1 if it’s not possible due to some reasons).
1. Understand
We understand that an Agile team should be co-located, but we are also aware that frequently it is not possible. This is especially true for technical writers because many companies cannot afford to dedicate a technical writer to a single product. We start every project with a kick-off meeting to review the documentation scope, backlogs, release goals and create a communication plan. Then, we agree on the agile planning tool so that we can create our tasks and present the feature documentation at the end of the sprint.

    Key Steps
  • Define Goals and Objectives
  • Create a Communication Plan
2. Backlog is our best friend!
Once we agree on the communication plan, we’ll study your product backlog and we’ll conduct a full product audit to see what currently exists and how best to document the new requirements. Then we’ll document our tasks and get client sign-off. This ensures that we don’t forget stuff which can eat up our time during the hardening phase. We’ll also agree on the technical writing tools, source control, and documentation delivery mechanism.

    Key Steps
  • Complete Product Audit
  • Define Technical Writing Tasks
  • Access Documentation Delivery Mechanism
3. Information Architecture
Our technical writers understand the users before they start creating documentation. We look at personas and understand their goals and the product usage pattern. Then, we mock up the structure (TOC) of each of the documents, clearly defining the topics and their information types. We love only three information types: Concept (overview information), Task (procedural information), and Reference (factual information). Once the structure of all the documents is approved, it’s time to get into sprints.

    Key Steps
  • Understand User Personas
  • Create TOC
  • Sprint Planning
4. Document Design
We always create document templates using existing brand guidelines. We are minimalists and are aware that people don’t like to read long and boring user manuals. We ensure that our technical writing teams write in such a way that users can get to their information quickly and intuitively. Our technical writers love working with XML and Darwin Information Typing Architecture (DITA).

    Key Steps
  • Create Template
  • Minimalism
5. Write++
Once we are part of the scrum teams, we attend sprint planning and daily scrum meetings. We understand the user stories and create documentation tasks. Then, we start authoring self-contained units of information about a specific topic. We always use a collaboration tool, such as Wiki or Microsoft OneNote to gather information from developers, testers, and product managers. Once we write the topics, we send them for technical reviews and fix the errors, if any. To ensure a productive relationship between dev teams and technical writers, we encourage clients to mark a user story as NOT DONE if the end-user documentation is not complete.

    Key Steps
  • Create a Development Environment
  • Develop Site Templates
  • Build CMS
  • Upload Content
6. Demo and Publish
We conduct rigorous editorial reviews to confirm that technical writing is as per the standard rules of English. We ensure that it follows the global English guidelines. We also check whether screenshots, flow charts, and conceptual diagrams meet the graphic guidelines. Then we fix any grammatical or style errors we find, including optimizing graphics, checking for broken links and making sure everything looks right. At the sprint review meeting, we demo the documentation and once the product owner accepts the documentation, we publish it on the documentation portal or the documentation branch.

    Key Steps
  • Review Grammar and Style
  • Review Graphics
  • Documentation Demo
  • Publish Documents