Step one — connect
Siraj reads what you already run.
Read-only. No migration, no new system for your staff to learn.
POSPoint of sale
TKTRepair tickets
STKBranch stock sheets
WAWhatsApp Business
PDFSupplier invoices
Step two — the problem, in your words
No specNo ticketNo dashboard to configure
Step three — investigate
Working the data like an engineer on site.
Records read
0
Sales
0
Repairs
0
Messages
Repair turnaround — days to close
Step three — testing what it thinks
It checks its own answer before giving it to you.
Hypothesis 1 — not enough technicians.
Tested against 3,120 tickets: technicians were idle 41% of working hours. Capacity is not the constraint.
Rejected
Hypothesis 2 — repairs are waiting on parts.
63% of total repair time is a ticket sitting open, waiting for one component to arrive. Screens account for most of it.
Holds — kept digging
Hypothesis 3 — the part was already in the building.
Cross-referenced branch stock sheets against order dates: 38% of parts ordered from the supplier were in stock at another branch that same day.
Confirmed
The finding you didn't ask for
3.1×
Customers whose repair took more than four days were 3.1× less likely to buy their next phone from you.
The slow repair isn't costing you repair margin. It's costing you the next sale — which is roughly nine times larger.
● Estimated JOD 47,000 / year
How it got there — cross-system join
repair tickets⋈
sales history⋈
whatsapp threads
Repeat purchase within 12 months
No dashboard was ever going to ask this question.
Step four — build
Working software, not a slide with a recommendation.
Shipping in this fix
+Cross-branch parts lookup, before any supplier order
+Per-part reorder points from real failure rates
+Day-3 WhatsApp update with a loaner offer
+Owner alert when a ticket passes 4 days
Built against your constraints
Runs on the sheets and WhatsApp number your staff already use. No new app for the technicians. Arabic messaging, sent from your own business account.
Step five — backtest
Replayed against 14 months of your own history, before touching anything live.
3,120 historical tickets, re-run through the fix
Amber = would have closed in under 3 days
Projected turnaround
6.2d→—
Projected repeat purchase rate
31%→—
Flagged for a human
14 edge cases where the loaner offer shouldn't fire — warranty disputes and water damage. Excluded pending your call.
Step six — your call
Nothing ships without you.
Awaiting approval
Route repair parts between branches before ordering
ChangesWhere a part is sourced from. Pricing, staff and routes untouched.
TouchesStock sheets, the repair ticket sheet, your WhatsApp Business number.
ExpectedTurnaround 6.2 → 2.6 days within one month.
RollbackOne click. Everything reverts to supplier-first ordering.
Approve and deploy
Request changes
Step seven — deploy
Live in your business in under four minutes.
✓Parts router deployed to all 3 branches
✓Reorder points written into the stock sheet
✓WhatsApp templates approved and scheduled
✓Owner alerts routed to Nabil's phone
✓Measurement started — baseline locked at 6.2 days
Step eight — measured, 30 days later
Repair turnaround — the KPI it promised to move
6.2d→—
● Verified against your own data
Repeat purchase rate
31%→—
Revenue recovered — month one
—
Annualised: JOD 74,000
What Nabil did
Approved one change. Then went back to running his shop.
And then it gets smarter
Every engagement teaches the next one. Your data stays yours.
Shared layer — patterns only, never data
Cross-location stock blindnessv4 · learned here
Service delay → churn couplingv2 · learned here
Reorder point driftv7
Queue congestion at batch releasev3
Unprompted — engagement 002
The same pattern is running in your accessories stock.
Siraj found it on its own, using what it learned here. Estimated JOD 19,000 a year. Want it to take this one?
Start engagement
Not now