Favour Kelvin · Technical Writer & Documentation Lead · London LinkedIn Portfolio Writing samples

Eseye Documentation V2

Rebuilding how documentation is created, managed and shared across the business.

Role
Technical Writer & Documentation Lead
Company
Eseye · IoT connectivity
Year
2026
Website
docs.eseye.com

Overview

Eseye is a global IoT connectivity company that helps businesses connect, manage and monitor devices across networks worldwide. Its products and services support enterprise customers and telecommunications partners, making clear, accessible technical documentation an important part of the customer experience.

The company wanted to modernise its documentation, which was primarily maintained in MadCap Flare, with additional content spread across different systems and teams. The existing setup made updates difficult, limited contributions from subject matter experts and wasn't well suited to supporting documentation across multiple partner brands.

As Technical Writer and Documentation Lead, I took ownership of a six-month project to transform how documentation was organised, created, reviewed and published.

I led the migration to GitBook, established documentation standards and automated contribution workflows, trained employees across the business and designed a shared content architecture supporting Eseye and its partners, including AT&T, MTN and TELUS.

The goal was to build more than a new documentation website: a sustainable system that made technical information easier to access and allowed teams across the business to contribute and maintain it consistently.

The four main goals

  1. Migrate from MadCap Flare to GitBook

    Move the existing documentation into a modern, centralised platform, improve the information architecture and make content easier to find, update and maintain.

  2. Build sustainable documentation processes

    Establish writing guidelines, content templates, governance standards and automated workflows so documentation could be created, reviewed and published consistently.

  3. Educate and empower teams across the business

    Give subject matter experts (SMEs) in engineering, product, support and other departments a straightforward way to contribute, supported by practical guidance and training.

  4. Build scalable documentation for partner brands

    Create a shared content architecture for Eseye, AT&T, MTN and TELUS, allowing each partner to have its own branded documentation experience while reusing common content and structures.

1. Moving from MadCap Flare to GitBook

The first step was finding a platform that could support Eseye's documentation requirements, including collaboration, version control, multiple audiences and partner-specific sites.

I evaluated Mintlify, Document360, Fern and GitBook, building proofs of concept to compare their capabilities and suitability. I recommended GitBook and led the migration of the existing documentation from MadCap Flare and other sources.

To support the migration, I connected Claude to GitBook through MCP to help process and restructure content at scale. I also introduced GitHub Actions for validation and Git Sync to connect documentation changes with GitBook.

Redesigning the documentation experience

The migration was an opportunity to improve how readers found information, rather than simply reproduce the old website. Previously, the documentation homepage was organised around product categories. This assumed readers already knew which Eseye product contained the information they needed.

I redesigned the homepage around common user tasks, such as integrating with an API, installing a router or managing connectivity.

Before The old Eseye documentation homepage, built in MadCap Flare, with a dark blue banner and four product category cards After The new Eseye documentation homepage in GitBook, with task-based cards such as I'm integrating with the API and I'm installing a router Before After

Drag to compare. The new experience gives readers a clearer starting point and helps them navigate based on what they want to accomplish.

I also launched separate public and internal documentation experiences, with Microsoft sign-in for internal users and access controls to distinguish public and internal content.

2. Building documentation standards and publishing processes

Moving to GitBook addressed the platform limitations, but the documentation also needed a consistent way to be created, reviewed and maintained.

I established documentation standards and governance covering writing conventions, terminology, content structure, templates and review requirements. These standards gave contributors a common framework to follow, regardless of their department or technical writing experience.

Automating content contributions

One of the most important parts of the project was removing the technical barriers that prevented employees from contributing. Not everyone needed to learn GitHub, Markdown or GitBook just to share product knowledge.

I designed an automated contribution workflow using tools employees were already familiar with: Word and SharePoint.

  1. A subject matter expert completes a structured Word template and submits it through SharePoint.
  2. Power Automate transfers the submission into GitHub.
  3. A scheduled Claude agent processes the content, applies the documentation structure and prepares the GitBook files.
  4. A pull request is created for review.
  5. The content is checked against the documentation standards before publication.
  6. The contributor receives an email with the outcome.

The process separates content creation from the technical work of preparing and publishing documentation. Contributors can focus on sharing accurate information, while the workflow provides structure, version history and a review step before publication. For employees who prefer working directly in GitHub or GitBook, those options remain available.

3. Educating and enabling teams across Eseye

A new platform and publishing workflow would only be useful if employees understood how to use them. I worked on making documentation more accessible to the people who knew Eseye's products best, particularly teams in engineering, product and support.

I created contributor guides, Word templates and training materials explaining how to submit documentation, follow the writing standards and participate in the review process. I also delivered training sessions to introduce the new system and show employees how they could contribute without needing specialist documentation tools.

This was an important part of changing the way documentation was managed. Instead of treating documentation as something handled exclusively by a technical writer, the new approach gave subject matter experts a defined role in keeping information accurate and up to date. The standards, training and automated workflows work together to make contributing easier without sacrificing editorial oversight.

4. Building documentation for multiple partner brands

Eseye also needed documentation experiences for its partners, including AT&T, MTN and TELUS. Maintaining separate copies of shared content would have introduced unnecessary duplication and made updates harder to coordinate.

I designed a single-source content architecture that could support multiple branded documentation sites while keeping common information centralised. The sites share navigation patterns, page structures and reusable content, with flexibility for partner-specific terminology, information and branding.

Same structure, different brands

Each partner has its own visual identity, but the underlying documentation follows a consistent approach.

AT&T IoT documentation homepage preview in blue, with the same task cards as the Eseye site
AT&T documentation
TELUS IoT documentation homepage in purple and green, with the same task cards
TELUS documentation

By separating shared content from brand-specific presentation and information, the documentation can support different partners without requiring every page to be maintained independently. This also provides a foundation for additional partner documentation sites as the business grows.

5. Making documentation AI-ready

Alongside the four main goals, I worked on making the documentation easier for AI tools to retrieve and use. GitBook's AI assistant allows readers to ask questions and receive answers grounded in the documentation.

I structured pages with descriptive headings, focused content, consistent terminology and clear information hierarchies to support both human readers and AI-powered retrieval.

I also developed an approach to using AI assistant interactions as documentation feedback. Questions that cannot be answered adequately, together with user feedback, can highlight missing information or content that needs improvement. This creates a feedback loop between the questions customers ask and the documentation the business maintains, helping teams identify where additional guidance is needed.

What this project achieved

Over six months, I delivered more than a new documentation website. I established the platform, content architecture, standards and workflows needed to support documentation across multiple teams and brands.

The result is a documentation system designed not only for publishing information, but for helping the wider business create, maintain and improve it.

Explore the live Eseye documentation →