← All work
Case study 03 · Settly · 2024–Present

Vendor Communication Platform

A centralized vendor communication system that cut response times by 50%, ended inbox fragmentation, and created the infrastructure for AI-driven relocation automation.

Role
Senior Product Manager
Timeline
2024–Present
Scope
Strategy · Design · Rollout
Team
1 PM · eng · ops
50%
Reduction in vendor response time
40%
Increase in user retention
70%
Vendors connected with email comms
1
Central hub replacing scattered inboxes
01

Strategic context

A strategic risk was becoming obvious: Settly's product value gets diluted whenever communication and documents move off-platform. The differentiation isn't that we can email vendors — it's that we provide a central hub for relocation work: timelines, documents, milestones, next steps, and increasingly automation.

Two drivers made it urgent. Internationalisation — as we expand, we rely more on external vendor networks to deliver in new markets, so a scalable vendor network is the first layer of international scaling. And platform strategy — centralised workflow is the prerequisite for automation, AI assistance and operational control.

Without centralizing communication and documents, Settly can't fully behave like a platform — and can't unlock AI-driven operational control.

Settly supports complex relocation cases requiring daily coordination with hundreds of vendors across services, at highly uneven interaction frequency. One constraint emerged early and shaped everything: onboarding every vendor to a platform is not feasible. Vendors already operate in their own systems.

02

Problem identification

Four problems, each compounding the others.

Problem 01 · Fragmentation

When vendor communication happens in email, the platform stops being the source of truth. Documents scatter and case progress is opaque to anyone outside that host's inbox — critical for international expansion.

Problem 02 · Vendor reality

Some vendors use shared inboxes, others spawn new threads mid-process, many are backed by internal systems. Perfect orchestration is unrealistic — we needed workflows resilient to messy vendor behaviour.

Problem 03 · Switch-tasking

Hosts copied case details from platform to email by hand, chased approvals across threads and updated statuses manually. High operational load and continuity loss whenever a host was out of office.

Problem 04 · Vendor data

Vendor information sat in inconsistent formats across spreadsheets, policies and drive folders. Hosts cross-checked several sources to find the right context — a scaling blocker as vendor complexity grew across markets.

03

What I did

I led work across three tracks simultaneously.

  1. 01Discovery and workflow mapping — mapped relay versus direct vendor patterns and captured the failure modes: new threads, missing CCs, handovers, context lost across markets.
  2. 02System design and product definition — decided what had to become structured data (vendor entities, status, case and service linking) versus what could stay unstructured but centralised (email content, attachments, replies).
  3. 03Feasibility exploration — validated that an email-first integration could work technically and operationally, linking vendor email reliably to case threads without requiring vendor onboarding.
The defining principle

Centralise communication and documents inside Settly, while letting vendors keep using email. The platform had to meet vendors where they are, not where we'd prefer them to be.

04

The solution

Five capabilities, built so that no vendor has to change how they work.

INITIATE → REPLY → CAPTURED
01

Email threading without vendor onboarding

Communication is initiated from inside Settly and vendor replies are captured back into the platform thread — shared visibility for the whole team instead of context trapped in one inbox.

VAULT → CONVERSATION
02

Documents in the communication loop

Hosts share documents from the platform vault straight into vendor conversations, cutting re-uploads and scattered attachments. The platform stays the source of truth.

TEMPLATE → CASE VARIABLES
03

Templates with case variables

Initiation emails generate from templates with case variables, removing manual assembly and keeping consistency across cases and markets.

PILOT → COHORT → ALL
04

Gradual, host-controlled rollout

A high-stakes workflow, so rollout was deliberately conservative: hosts chose when to activate, starting with pilot users where compatibility was guaranteed.

PRIMARYSECONDARYHISTORICAL
COMPANY · SERVICE · VENDOR
05

Vendor management foundation

Structured vendor data — vendors linked to companies and services, preferred vendors surfaced — which solved the spreadsheet reconciliation problem and made later automation possible.

05

Outcome & impact

50%
reduction in vendor response time
40%
increase in user retention
70%
vendors connected on launch

Beyond the metrics this laid the structural foundation for Settly's next growth phase. The centralised communication layer is the prerequisite for international scaling, for automation and AI leverage — reminders, summarisation, policy checks, routing — for operational resilience against handover risk, and for platform retention, since documents, conversations and next steps now live in one hub. This was never an email feature.

06

What I'd do differently

Build the vendor directory first, not last. It shipped as the fifth capability, but every earlier one would have been simpler with structured vendor data already in place.

Give hosts a migration path for threads already in flight. Pilot users ran two systems in parallel for longer than they should have needed to.