Carlos EscasainCommercial Systems & Process Architect
ENES

Operating Model & Process Design / 10 · Intake → resolution → learning

Standardizing customer service from intake to resolution—and back into commercial action

A fictional case about the operation behind a service case: not implementing a case object, but deciding what a case is, who owns it and what the organization does with what it learns.

Fictional scenario8 min readUpdated 29 Sep 2026
Fictional scenario

Independently created. Contains no employer or client implementation detail, internal names or figures.

The case in brief

Current reality

Service requests arrived by email, phone and forms, were handled by whoever picked them up, closed when a reply was sent—and never reached sales when they signalled a problem with the account.

What must become true

Every service request is identified, classified and owned on entry, resolved within a service level that matches its severity, closed by explicit criteria—and, when it signals risk or opportunity, turned into commercial action someone owns.

Design question

What counts as a service case, who owns it until it is truly resolved—and when does a service issue become a commercial signal?

01Reality

What the organization actually did.

A fictional manufacturer’s customer service team handles order queries, delivery problems, product complaints, technical questions and returns for distributors in several countries. Each team had its own habits, and sales heard about service problems from the customer.

  • Requests arrived by email, phone and web forms, each handled differently
  • Customer identity was guessed from the sender’s address
  • Severity was whatever the customer said it was
  • Cases were closed when a reply was sent, not when the issue was solved
  • Repeated issues were never linked
  • Sales learned about service problems from the customer

02One process?

What made one process insufficient?

One queue treated a delivery question and a quality complaint alike. What made them different:

  1. Request typeQuestion, order issue, delivery problem, complaint, return or technical support?
  2. Customer identityWhich account and legal entity—confirmed, or assumed?
  3. SeverityBusiness impact, safety or quality risk, customer importance?
  4. OwnershipService alone, or quality, logistics or engineering too?
  5. Service levelHow fast must we respond—and resolve?
  6. RecurrenceNew, or the third time this quarter?
  7. Commercial signalDoes it suggest churn risk, deterioration or an opportunity?

The pointCustomer service ends when the issue is resolved operationally; the organization still has to decide what it learned and whether commercial action is required.

03Segmentation

How the reality was segmented

Classes by type and severity decide the owner, the route and the clock.

FromEvery incoming request

  1. EnquiryInformation requests: answered by service, at first contact where possible.
  2. Order and delivery issueService owns it; logistics or finance are consulted.
  3. Complaint or qualityService owns the customer; quality owns the investigation.
  4. Technical supportTechnical specialists own the answer.

Design decision

Standardize the service lifecycle and its decision rules first; treat channels, routing and automation as supporting capabilities of that lifecycle.

04Target model

Target operating model

One lifecycle for every channel; the class decides the owner, the clock and the closure criteria.

  1. Intake
    Owner
    Service agent, or rule
    Exit criterion
    Request captured from any channel into one queue
  2. Qualify
    Owner
    Service agent
    Exit criterion
    Customer identified; type, severity and class set
  3. Ownership
    Owner
    Rule by class
    Exit criterion
    One owner; routed, with the service level started
  4. Resolve
    Owner
    Owner, with the specialist function
    Exit criterion
    Operational fix delivered and confirmed
  5. Escalate when needed
    Owner
    Service lead
    Exit criterion
    Breach or severity handled by the escalation owner
  6. Close
    Owner
    Owner
    Exit criterion
    Closure criteria met; cause code recorded
  7. Learn and signal
    Owner
    Service lead with the account manager
    Exit criterion
    Recurring causes and commercial signals routed to owners

05What changes by path · Intake → resolution → learning

What changes by class

Channels are entry points. The class decides the rest.

What changes by class
DimensionEnquiryOrder and deliveryComplaint or qualityTechnical
OwnerServiceServiceService (customer), quality (cause)Technical specialist
Consulted—Logistics, financeQuality, plantEngineering
Response clockSame dayOne working dayOne working dayTwo working days
Resolved whenAnswered at first contactDelivery or credit fixedInvestigation concludedAnswer confirmed
Closure evidenceAnswer sentFix confirmedRoot cause and actionSolution accepted
Commercial signal?RarelyIf repeatedAlways reviewedIf it shows a product gap
Path 01Enquiry
Owner
Service
Consulted
—
Response clock
Same day
Resolved when
Answered at first contact
Closure evidence
Answer sent
Commercial signal?
Rarely
Path 02Order and delivery
Owner
Service
Consulted
Logistics, finance
Response clock
One working day
Resolved when
Delivery or credit fixed
Closure evidence
Fix confirmed
Commercial signal?
If repeated
Path 03Complaint or quality
Owner
Service (customer), quality (cause)
Consulted
Quality, plant
Response clock
One working day
Resolved when
Investigation concluded
Closure evidence
Root cause and action
Commercial signal?
Always reviewed
Path 04Technical
Owner
Technical specialist
Consulted
Engineering
Response clock
Two working days
Resolved when
Answer confirmed
Closure evidence
Solution accepted
Commercial signal?
If it shows a product gap

Clocks are illustrative. The design choice is that closure means the issue is solved and its cause recorded—not that a reply was sent.

06Exceptions and return paths

The happy path is never the whole process.

When
WhenThenOwnerReturns to
The customer cannot be identifiedHeld in qualification; never assigned to a guessed accountService agentQualify
The service level is at riskEscalated to the service lead before the breachService leadResolve
The customer reopensThe case is reopened, not duplicated; recurrence is countedOriginal ownerResolve
A cause recurs across customersRaised as a problem to the owning functionService leadLearn and signal
A signal of churn riskTask to the account manager with the case contextAccount managerThe account management loop

07Supporting capabilities and system encoding

Only now, the technology.

Systems and partiesCRM serviceEmail and web intakeERPKnowledge base

Supporting capabilities

  • Email and web intakeBrings every channel into one queue
  • Routing rulesApply ownership by class and severity
  • Knowledge baseAnswers enquiries at first contact
  • AI assistanceSuggests type and severity for review—see the commercial email case
  • Service analyticsSurfaces recurrence and account-level signals

How the system encodes the model

  1. Operating decision: One lifecycle, any channel

    System response: Channels create cases in one queue, with the channel recorded

  2. Operating decision: The class decides owner and clock

    System response: Routing and service-level policies by class and severity

  3. Operating decision: Closure means solved

    System response: Closure requires resolution confirmation and a cause code

  4. Operating decision: Service feeds commercial action

    System response: Signals create tasks for the account manager; the account shows open service issues

08Measurement

What is measured—and what it triggers.

Metric
MetricWhyOwnerCadenceTriggers
Resolved within the service level, by classResponse time alone hides unresolved casesService leadWeeklyRebalance capacity or routing
Reopen rateTests whether closure meant resolutionService leadMonthlyTighten closure criteria
Recurring causesService can absorb systemic problems, not fix themOwning functionsMonthlyProblem actions with owners
Signals acted on by salesThe commercial loop must closeSales managersMonthlyFollow up on unacted signals

09The second layer

Questions that change the design.

Definition

  1. What counts as a service case—and what is a sales request?
  2. Who may set severity?

Ownership

  1. Who owns a complaint whose cause lies in a plant?
  2. When does ownership transfer, and when is a specialist only consulted?

Learning

  1. When is a service issue a commercial signal?
  2. Who decides whether commercial action is required?

10Decisions & outputs

What the work produces.

  1. 01Service lifecycle
  2. 02Case classes and severity rules
  3. 03Ownership and routing model
  4. 04Service levels and escalation
  5. 05Closure criteria
  6. 06Service-to-commercial signal loop
Disciplines involvedProcess ArchitectureDigital Operating ModelAutomation