Yaravan — service design for an after-sales operation nobody had written down

01Context

A dormant identity, an undocumented operation

Yaravan is the warranty and after-sales brand of an Iranian mobile-phone retailer. An outside agency wrote its brand identity in 2024, and then nothing was built on it. From July 2026 the job was to turn it into a working service: a public website, a customer panel and a staff panel — and, underneath them, the operation that would have to keep the brand’s promises.

The existing support system keeps the ticket queue and the repair operation. For the processes Yaravan owns, the relationship runs the other way: Yaravan is the operations reference, and the support system records the process rather than running it. This case study is about that operation; the product built on top of it is a case study of its own.

02Problem

A design of the desired state, not a record of the current one

The operation had never been written down. The requirements and the functional specification both cited two source documents — an after-sales requirements document and a CRM process report — as the origin of the real ticketing, repair and warranty processes. Neither existed in any repository.

So every process map would have to be a design of the desired state, not a record of the existing one, and the process set carries that warning on its front page. Meanwhile the brand’s public promises had already outrun the operation: the requirements work found that the old site’s headline claims were not operational truth, and that no real warranty database existed.

That set the design question for the operation: how do you draw a process nobody can yet confirm, without inventing it?

03My role

Leading the work, with the client’s team

I led the service design — the readiness audit, the process architecture, the role model and the warranty economics. Business ownership stayed with the client: its business lead owned the commercial decisions, and its after-sales lead owned the support operation and reviewed the maps.

Owned

Requirements and scope
The input-readiness audit
Process architecture, macro map to work instruction
Roles, responsibilities and the RACI
Warranty economics

Co-owned

The platform build the maps were read from, with the client’s engineering team

Collaborated

Commercial decisions (the business lead)
The support operation and its review notes (the after-sales lead)

The file was built with AI assistance: review fixes were applied by an agent working through the Figma integration and logged thread by thread. The drawing rules and the evidence tiers it had to obey were written first.

04Approach

Gates, not deliverables

Each stage ended in a gate rather than a document. The requirements came from fifty direct multiple-choice questions to the business lead, a review of the brand and source documents, and a benchmark of nine competitors, against one success test: engineering can start without re-asking any fundamental question.

Then a readiness audit ran — and failed. Across 59 sources and 31 processes it returned NOT_READY, with 12 blockers, 4 unresolved conflicts and roles in three inconsistent taxonomies. The second round did not argue with the verdict; it cut the scope to the 13 processes the brand actually owns, and a later amendment widened it to 22, adding intake, diagnosis, repair, return delivery and parts.

Cutting scope raised structural readiness from 49% to 78% and evidence confidence from 58% to 92% — because the processes left in scope could be read off executable code and passing tests.

“NOT_READY is not to be replaced by any positive percentage or optimistic narrative.”
— The input-readiness audit, round one · A rule written into the audit before it ran

Six gates, in order

01
RequirementsFifty questions to the business lead; nine competitors benchmarked
02
Readiness auditNOT_READY: 12 blockers, 4 conflicts, roles in three taxonomies

05Research

Draw the rules before the diagrams

The Figma file holds no screens: the interface was specified in writing, and the design effort went into the part nobody could describe — the operation. Its first page is not a cover but a rules page: a fourteen-part component library and six house rules. Flow runs right to left, as the language does. Blanks are marked “needs determination”, never filled with a guessed name or number. Conflicts are recorded, not resolved. Colour never carries meaning alone; it always travels with a shape and an icon.

One rule decides the shape of the whole file: what may be drawn depends on the evidence behind it, claim by claim. Five evidence tiers run from executable code, which licenses a full swimlane, down to no source at all, for which drawing is forbidden and only a notice may appear. The lower the tier, the less you may draw.

So the file is honest about its absences. Where a level stops short, a notice board names what is missing and why, and the service-map and swimlane notices close their own arithmetic back to 22. A diagram of an undocumented sequence would be the same invention the rules forbid — only more convincing.

Yaravan — the rules section of the design guide in Persian: six house rules, the scope amendment and the five evidence tiers — Figure 02Page 00’s rules: six house rules, the amendment that widened the scope to 22 processes, and the five evidence tiers that decide what may be drawn. Lines naming the retailer or the support system are removed.

Yaravan — the diagram component library: seven flow shapes, a four-state status badge, lane headers, breadcrumbs and process cards

06Six levels

One process, followed all the way down

The architecture has six levels, and each answers a different question. Customer warranty activation is one of the few processes drawn at every one of them, so it shows the whole stack. On the macro map it is one card with an owner, an output and a status. At level 1 it becomes an end-to-end card: trigger, owner, start and end events, four phases, the decision gates, what it takes in and hands on, the controls the code enforces — and a KPI and SLA marked “needs determination”, because no approved formula or time exists in any source.

Level 2 is a service blueprint: the customer’s actions, the touchpoints, and what staff and systems do on each side of the lines of interaction, visibility and internal interaction, down to the records and controls each step leaves behind. Here it shows that the printed label the customer starts from is a touchpoint the system does not control — printing happens outside it. The file draws that touchpoint too: a printable warranty card, front and back, in ten variants. Level 3 turns the same sequence into a swimlane with a lane for each actor.

Levels 4 and 5 are for the people who run it. The procedure covers four processes at once — procedures and processes are not one-to-one — and is stamped “not approved”, with its approver and review date left as “needs determination”. The work instruction is the customer’s own seven steps, with a checklist written for them: the code alphabet has no zero, O, one, I or L, so nothing on the printed label can be misread.

Each level is allowed to stop. Only fourteen of the 22 processes have a swimlane and only six have a blueprint; the rest have a notice saying why, and the notices close their own count back to 22.

Yaravan — the front of the printable warranty card in Persian: device model, warranty code, expiry date, an empty contact field and a blurred QR code — Figure 04Where activation starts: the front of the printable warranty card on page 11, one of ten variants. The legal entity, address and phone are removed, and the QR code is blurred.

Yaravan — the end-to-end card for customer warranty activation in Persian: trigger, owner, phases, decision gates, inputs and outputs, controls, and a KPI and SLA marked as needing determination — Figure 05Level 1 — customer warranty activation end to end: trigger and owner, four phases flowing right to left, the decision gates, and a KPI and SLA that no source defines yet.

Yaravan — the service blueprint for customer warranty activation in Persian: four steps across layers from customer actions to evidence, divided by the lines of interaction, visibility and internal interaction — Figure 06Level 2 — the service blueprint: four steps from reading the label to an active warranty, across the lines of interaction, visibility and internal interaction.

Yaravan — the swimlane for customer warranty activation in Persian: customer, system and SMS lanes, one decision and two end states — Figure 07Level 3 — the swimlane: the customer, the system and the SMS gateway in three lanes, with the one decision that sends a used code to rejection.

Yaravan — the identity card of the activation-code procedure in Persian: version 0.3 draft, approver and review date needing determination, and the status “not approved”

Yaravan — the work instruction for activating a warranty code in Persian: identity, preconditions, the panel path and seven numbered steps

07What the maps found

A map that may come back incomplete is a research instrument

Drawing the operation produced findings no document had. Of the fourteen processes drawn as swimlanes, only two send an SMS at all — the login code and the warranty activation — so the draft message copy went into exactly those two maps. Four processes on the macro map have no card, because the sources cited for them do not exist.

Where a level cannot be drawn honestly, a notice takes its place. Six work instructions cannot be written yet, each for a named reason: no reset mechanism, no ownership-dispute path, no invoice-number format, an open conflict, no photo standard, no policy for unclaimed goods. The repair-quality procedure got no work-instruction number at all — reserving one for a procedure whose performer is still open would itself be a claim.

The file also audits itself. A coverage matrix sets each of the 22 processes against its source, the levels that exist and what is missing: six complete, six incomplete, one in conflict, nine needing determination. It reopens three gaps that had been marked closed — closed is not the same as resolved by the organisation — and it withdraws its own citations where a source turned out not to say what it had been cited for.

Yaravan — three notice boards in Persian, from the service-map, swimlane and work-instruction pages, each listing what is not drawn and why — Figure 09Absences, drawn: the notices on the service-map, swimlane and work-instruction pages, each naming what is missing and why. Lines naming the retailer are removed.

Yaravan — the coverage matrix in Persian: a 22-row table of processes against their sources, levels and gaps, with status counts beneath — Figure 10Page 08: the coverage matrix — each of the 22 processes against its source, the levels that exist and what is missing, with the status counts beneath. Cells naming people, the support system or a code weakness are removed.

08Roles

Accountability is an organisational fact, not a technical one

Eight role cards set out each role’s purpose, duties, exclusive rights, deliberate exclusions and gaps, with the KPI and SLA marked “needs determination” on every card. Some cards are mostly questions. One role exists in the code and has access, but no business document, organisation chart or procedure defines it, so its lane is drawn dashed until the business decides whether it is real or another name for an existing role.

The responsibility matrix could only be three-quarters derived. Responsible, consulted and informed came out of the code; accountable could not, because the code says who can execute an action, not who answers for its result. The matrix ships with that column open and a banner saying so, and it marks deliberate exclusions — segregation of duties — in red so they cannot be mistaken for gaps: the role that sets the void ceiling cannot approve voids, because it could raise its own ceiling.

The access model got the same treatment. One page sets out eight structural controls the code enforces — deny by default, a 404 rather than a 403 so a role cannot learn that a page exists, and no invented defaults: “inventing a default means silently publishing a policy nobody approved.” Beside it, the after-sales staff’s own role proposal — eight roles, 76 items — is checked against the code item by item, side by side, “not merged, not reconciled”. Three of the 76 are fully built and twenty conflict with an approved architecture decision, and the page states its own limit: it gives no verdict on whether the proposal is right.

Yaravan — the role card for warranty operations in Persian: a red banner saying the role exists in the code but in no business document, and every field marked as needing determination — Figure 11A role that exists only in the code: every field of its card reads “needs determination”, and the banner puts the question to the business.

Yaravan — the RACI matrix in Persian, with a red banner marking the Accountable column as open and red cells for deliberate exclusions — Figure 12The first eleven rows of the 22-process matrix. The main column ships empty, and says why. The banner states the gap and who holds the decision; the name is hidden here.

Yaravan — two boards in Persian: eight structural access controls enforced in the code, and the header of the comparison between the current model and the staff’s proposal — Figure 13Page 10: the eight structural controls the code enforces — deny by default, 404 instead of 403, one module behind menu, page and server — above the header of the side-by-side comparison with the staff’s own proposal.

09Key decisions

Six rules for drawing what nobody could confirm

Most of the method is about what the file refuses to draw.

01
Draw only as far as the evidence goes
Five evidence tiers, set per claim rather than per document, decide what may be drawn: executable code licenses a full swimlane, and no source at all licenses only a notice. A diagram claims to know the sequence, conditions, error paths and lane boundaries — drawing one without evidence is invention that merely looks more convincing.
Alternatives
Draw every process to the same depth from interviews and intent
Trade-off
The file looks uneven: some processes stop at a card.
02
Mark blanks, never guess them
No business information was invented. Where a name, a number or a time was missing, the field reads “needs determination” — on every KPI, every SLA and most approvers — so the gaps can be counted and assigned.
Alternatives
Plausible placeholder values
Trade-off
Stakeholders see a great deal of orange.
03
Record conflicts, don’t resolve them

10Economics

A warranty is a liability, not a service

The operation also had to answer what its central promise costs. A warranty delivers no service on the day it is issued — only a promise that, if the device fails within a period, someone pays. Whether a claim comes, when, and how much it costs are all unknown on that day, so money has to be set aside for it now, or the promise has nothing behind it.

The deck follows the obligation from issue to closure and sets out who could fund it — and each answer says what the brand is: if the retailer absorbs the cost, a cost centre; if sellers buy the codes, an independent business; if the importer pays, a partner running the network. The recommendation is labelled “a proposal, not a decision”.

It ends in controls ranked by cost — the cheapest is a single field — and ten decisions with owners and options, eight of which can be taken today without any number at all.

The only numbers allowed in the deck are ones extracted from the code, a hypothetical labelled as one, or an external benchmark with its source, population, date and confidence — and every slide carries a badge saying which.

Yaravan warranty economics — a slide in Persian: a warranty is a promise, with three unknowns at the moment of issue — whether, when and how much — Figure 14The deck opens on the concept: on the day it is issued, a warranty is three unknowns — whether a claim comes, when, and at what cost.

Yaravan warranty economics — five control levers in Persian, ordered from cheapest to costliest, each with its status today — Figure 15Five control levers, ordered from cheapest to costliest, each tied to the factor of the cost equation it moves.

Yaravan warranty economics — the deck’s board map in Persian: the narrative arc and a table of every slide with its message and evidence badge

Yaravan warranty economics — the glossary appendix in Persian: one fixed Persian term for each concept, with its definition

11Outcomes

A drawn operation, with its gaps owned

There are no business metrics, and there should not be: the product is on staging and the agreed measures have no approved formula or data source yet. What the work changed is what the organisation knows about itself. In July there was no written account of the after-sales operation; now there is a drawn one, with every gap marked, counted and assigned — and the three items blocking integration are named as decisions, not engineering.

22 processes at six levels: Macro map, end-to-end cards, service blueprints, swimlanes, procedures and work instructions — 145 boards on 13 pages.; Delivered output
A role model and a RACI: Eight role cards and a 22-process matrix, with deliberate exclusions marked and the open column admitted.; Delivered output
A coverage matrix that audits itself: Every process against its source, its levels and what is missing; closed gaps reopened and citations corrected.; Delivered output
A warranty-economics model: Liability, funding and controls, set out without a single invented number.; Delivered output

What was delivered

Readiness audit
Macro process map
Service blueprints
Swimlanes and procedures

12What I learned

One discipline, every board

01
Publishing the gap beats papering over it
The same instinct runs through every artefact: NOT_READY instead of a percentage, “needs determination” on the process cards, an empty Accountable column with a banner saying so, and an evidence badge on every slide.
02
A map that may come back incomplete is a research instrument
Drawing what nobody could describe produced findings no document had: which processes really message the customer, which roles exist only in the code, which column cannot be filled from permissions. A map that must look finished is decoration.
03
A readiness score means nothing until the scope is honest
The first audit failed because it measured an operation this product does not own. Restricting it to the processes the brand owns did not lower the standard — it raised evidence confidence to 92%.
04
Turn each review comment into a rule
Answering a comment fixes one node; naming the rule behind it fixes every future one. One note on Persian spelling became a named rule and a single pass over 1,088 text nodes on all thirteen pages.

Language

Yaravan — service design for an after-sales operation nobody had written down

A dormant identity, an undocumented operation

A design of the desired state, not a record of the current one

Leading the work, with the client’s team

Owned

Co-owned

Collaborated

Gates, not deliverables

Six gates, in order

Draw the rules before the diagrams

One process, followed all the way down

A map that may come back incomplete is a research instrument

Accountability is an organisational fact, not a technical one

Six rules for drawing what nobody could confirm

Draw only as far as the evidence goes

Mark blanks, never guess them

Record conflicts, don’t resolve them

A warranty is a liability, not a service

A drawn operation, with its gaps owned

What was delivered

One discipline, every board

Publishing the gap beats papering over it

A map that may come back incomplete is a research instrument

A readiness score means nothing until the scope is honest

Turn each review comment into a rule

Leave the Accountable column open

CRM as a verdict per process, not a feature

Persian on the canvas, Latin in the frame name