AccAnalysisAccAnalysis
Retail & E-commerce

A helpdesk live quickly, then made to fit how support actually works

A retailer's support team needed a working helpdesk fast, then needed it to grow into roles, permissions and ticket workflows for internal and external users — with the operational visibility that had never existed alongside it.

At a glance
Status
Delivered
Region
Germany
Engagement model
Dedicated team

Status: Delivered. Described from our own delivery records. Client identity, brand and commercial terms are withheld. Figures, where given, cover the period stated and nothing beyond it.

The organisation

Context

A retailer whose customer-support function served both internal colleagues and external trade customers from the same team.

It needed to start operating quickly — the standing up of the helpdesk could not wait for a full process design — and then needed the system to catch up with the complexity of the work.

The brief

The problem

  • Requests arrived through several channels with no single record of what had been asked or decided.
  • Internal and external users needed different visibility of the same ticket, and there was no permission model capable of expressing that.
  • Documents and files attached to cases had no controlled sharing, so sensitive material moved by email.
  • Ticket handling was uniform where the work was not — an urgent trade issue followed the same path as a routine internal question.
  • Nobody could see how the support function was performing, and trade customers had no visibility into their own cases at all.
The work

What we built

A helpdesk stood up quickly on standard modules

So the team had a working system before the redesign began — deliberately, because a support function cannot pause.

A role and permission model

Separating what internal staff, external trade users and administrators can see on the same ticket.

Controlled document management and sharing

Attached to the case record rather than to an inbox.

Dynamic ticket-processing workflows

With routing, escalation and service-level rules matched to ticket type rather than applied uniformly.

A reporting layer

Data pipelines feeding an analytics tool, with operational dashboards for the retailer and self-service dashboards for its trade customers.

Method

How we delivered it

  1. 1

    Fast start

    Standard helpdesk configured and live, to stop the bleeding.

  2. 2

    Observe the real process

    For a period, with the team, before redesigning it.

  3. 3

    Redesign in place

    Roles, permissions, document handling, workflow rules, applied incrementally rather than as a relaunch.

  4. 4

    Instrument

    Pipelines and a warehouse layer over the ticket and operational data.

  5. 5

    Publish

    Internal dashboards first, then the client-facing views once the underlying numbers were trusted.

Sequence

How it was phased

PhaseDurationWhat happens
1Fast start
2–3 wks

Standard helpdesk configured and in use

2Observation & mapping
2–3 wks

How support actually works, with the team

3Roles, permissions & documents
3–4 wks

Access model, file handling, sharing controls

4Workflow automation
3–4 wks

Routing, escalation, SLA rules by ticket type

5BI layer
4–6 wks

Pipelines, warehouse layer, internal dashboards

6Client-facing dashboards
2–3 wks

Self-service views for trade customers

Indicative phasing for work of this shape. Actual duration varies with data quality, access and decision speed.

Hand-over

What the client keeps

  • The production helpdesk
  • The permission matrix
  • Workflow and SLA configuration
  • Pipeline code in their own repository
  • Dashboards they can edit, and the metric definitions behind them
Stack
Odoo (Helpdesk)PythonMetabaseETL pipelinesPostgreSQL
Keep reading

Related

Related case studies

Tell us what your current system can't do, and we'll tell you what it would take to change that.