No result found
This report needs a scored result to generate.
This is a static sample and does not depend on a scored result.
Back to the programme page
PRAXORALAB Illustrative example · fictional company, for format reference only
Redesigned Workflow
Kestrel Freight Solutions
Built for one real team's own workflow, not a generic maturity model. Kestrel Freight Solutions's example team: the Customer Service & Claims team. Example use case: the freight-damage claims workflow, from a customer's first report to a settled claim.
Where the current workflow breaksA damage claim moves through five handoffs, intake, photo review, carrier liaison, settlement calculation, customer reply, and no one person owns it end to end. A claim can sit for two working days between handoffs with nobody actively working it.
A $40 dented-carton claim and a $12,000 pallet-loss claim wait behind the same queue, because nothing routes the small, obvious ones differently from the ones that genuinely need judgment.
The stage most likely to be redesigned away is, in fact, the one the team already runs well: response times from the three main carriers are tracked and mostly met. The redesign rebuilds around this stage rather than through it.
Stage 1 — Structured intake
A single intake form captures claim type, estimated value and photo evidence at first contact, replacing the email-then-chase pattern the team uses today.
Claims under $500 with clear photo evidence route straight to fast-track settlement, skipping stages 2 and 3 entirely.
Stage 2 — Owned triage
One named triage lead per shift reviews every claim within four working hours of intake, not whenever the queue is next checked.
The triage lead stays the single point of contact for that claim through to settlement or formal escalation.
Stage 3 — Carrier liaison (unchanged)
Kept exactly as it runs today. The team's own tracked carrier response times stay the benchmark, not a source of the delay.
Stage 4 — Settlement and reply
Settlement calculation and the customer-facing reply move into the same stage, closed by the same triage lead who opened the claim.
Five handoffs for a single freight-damage claim is not, on its own, an unusual number for a mid-market operations team; what turns it into a genuine constraint is that none of the five carries a named owner past the point of intake. The S.E.N.S.E. framework treats this as a Structure gap before it treats it as a technology gap, and Kestrel Freight Solutions is a clean illustration of why that ordering matters: the team already has the domain knowledge to settle a claim correctly, it simply has no single person accountable for carrying one claim through to close.
The decision to leave carrier liaison untouched is the more disciplined move on this page, not the more visible one. A redesign that reworks every stage because it can looks more thorough on a slide than one that reworks three stages and deliberately leaves a fourth alone. But Kestrel's own tracked data shows carrier liaison already performs against its benchmark; redesigning a stage that is not broken spends the team's limited change capacity on the wrong problem, and it is exactly the kind of unforced error I see teams make when a redesign session is run as a generic workshop exercise rather than against a team's own numbers.
The $500 fast-track threshold is the page's real structural change, and it does two things at once: it removes the majority of small, low-risk claims from a five-stage process built for the complicated ones, and it frees the newly named triage lead to spend their four-hour review window on claims that actually need judgment rather than claims that are obvious on sight. This is capability architecture in the literal sense the S.E.N.S.E. framework uses the term: not adding a tool, but changing who is accountable for what, and when, so that a tool introduced later has a role to sit inside rather than a vacuum to fill.
What I would watch in the first month, if this were a live engagement rather than this illustrative example, is whether the $500 threshold holds. Thresholds set in a workshop room are informed guesses, not measurements, and the roadmap on the final page of this sample is right to schedule a four-week check against actual claim volume rather than treating the number set here as final. A redesigned workflow that cannot be adjusted against its own early data is not a finished redesign; it is a hypothesis wearing the clothes of one.
Kestrel Freight Solutions and its claims workflow are invented for this sample only, to show the shape of the output, not a real client's actual process. In the session, this workflow is redesigned from the function a participant actually brings into the room.
PRAXORALAB AI-Literacy Baseline
Built for the Customer Service & Claims team, the same nine people taking on the redesigned workflow opposite, not a generic organisation-wide survey. Every score, note and quote below is invented for this sample only.
Overall Baseline ScoreDeveloping
A mixed profile: the team is willing and reasonably risk-aware, held back by generic prompting habits and AI use that sits outside, not inside, the claims workflow.
| Dimension | Score | Status | |
|---|---|---|---|
| Tool familiarity | 2 / 3 | Developing | |
| Prompt literacy | 1 / 3 | Blocker | |
| Risk awareness | 2 / 3 | Developing | |
| Workflow integration | 1 / 3 | Blocker | |
| Confidence & adoption | 2 / 3 | Developing |
Priority: Prompt literacy
Prompts are short and vague, 'write a reply about this claim', producing generic drafts that need heavy rewriting, the single biggest time cost the session surfaced.
An eight-out-of-fifteen baseline is, in my experience running this exercise across markets from Singapore to Johannesburg, closer to the median first-time score than either a nervous team or a confident one expects. What matters more than the total is the shape underneath it, and Kestrel's shape is a genuinely common one: a team that already trusts AI enough to use it, and doesn't yet know how to use it well enough to trust its output without rewriting it.
Prompt literacy scoring the floor of this scorecard, at 1, is the finding I would lead with in the room, not the finding I would bury under the total. "Write a reply about this claim" is not a bad instinct, it's an incomplete one, and the gap between that prompt and one that actually saves the drafting time the team is hoping for is a skill, not a talent. It is also, encouragingly, the fastest of the five dimensions to move: across twenty-plus markets of HR transformation work, prompt literacy is consistently the dimension that improves fastest with structured practice, faster than risk awareness and much faster than the cultural shift workflow integration requires.
Workflow integration tying for last place is the quieter, more structural problem, and it isn't really a literacy gap at all, it's a design gap sitting one layer below the people. A team drafting in a separate browser tab and copying the result back by hand isn't choosing to work that way out of habit; it's working around a tool that was never given a seat inside the claims system itself. No amount of prompt training fixes that on its own, which is exactly why the roadmap moves the Claims Intake Summariser inside the actual intake form in the first three weeks, rather than leaving it as a side tool the team has to remember to open.
The number I would not let get lost in a scorecard reading is the two of nine who told us, honestly, that they expect to stop using AI within a month without a follow-up. That is not a training failure; a new tool losing momentum after the initial session is one of the most consistent patterns I have seen in every market I have worked in, because technology adoption curves and human attention curves are not the same shape. Building a monthly check-in into the roadmap for exactly those two people, rather than assuming the whole team's enthusiasm holds at the same rate, is the difference between a baseline that gets re-scored higher in twelve weeks and one that quietly slides back to where it started.
The AI-literacy scores, notes and quotes above are invented for Kestrel Freight Solutions, a fictional company, for illustration only. In the session, this scorecard is built from your own team's actual baseline, not assigned from a template.
PRAXORALAB Working AI Applications
Built on the Customer Service & Claims team's own tasks during the session, not assigned from a use-case library. Two to three applications is the usual range for a half-day build; Kestrel Freight Solutions's example team built three.
3
Working applications built in the session, on the team's own tasks
~12 min
Estimated drafting time saved per claim, self-reported by the team, not independently measured
Claims Intake Summariser — Built by the two intake officers
Turns a customer's freight-damage report, the email text plus photo descriptions, into a structured summary: claim type, estimated value band, and a suggested fast-track or full-review flag.
Human-check boundary: The tool suggests the flag. The named triage lead, not the tool, makes the fast-track decision for anything above the $500 threshold.
Claims Status Reply Drafter — Built by three case handlers
Drafts a status-update email to a customer, given the claim's current stage and the last note logged against it, in Kestrel's own reply tone rather than a generic register.
Human-check boundary: Every draft is reviewed and sent by the case handler named on the claim. The tool never sends an email directly to a customer.
Similar-Claim Finder — Built by the triage lead
Surfaces the three most similar past claims and how they were resolved, given a new claim's description, so a case handler starts from precedent rather than a blank page.
Human-check boundary: A precedent is a starting point, not a decision. Every settlement figure is still calculated fresh against the current claim's own evidence.
Three applications from one half-day session is about right, and I say that as someone who runs AI adoption inside an actual manufacturing operation, not only as someone who teaches it. The mistake most teams make in their first build session is trying to automate the whole claim end to end in one go, and what usually gets shipped is either too ambitious to trust or too narrow to matter. Kestrel's three tools avoid both traps because each one attaches to a task someone on the team was already doing badly or slowly, not a task someone imagined they might want automated someday.
The Claims Intake Summariser is the one I'd watch closest in week one, precisely because it sits earliest in the workflow the companion redesign on page one now depends on. A suggested fast-track flag that the intake officer can override is the right shape of tool: it does the reading, a person still makes the call. What I'd push the team on, in a live engagement, is whether that override actually gets used, or whether it quietly turns into a rubber stamp within a month. A boundary that exists on paper and a boundary a team actually exercises are two different things, and the only way to know which one you've built is to check the override rate, not to assume good intentions carry it.
The Claims Status Reply Drafter is the safest of the three by design, and deliberately so: it never reaches a customer without a person reading it first. That's the right call for a first build, not a permanent ceiling. Once the team trusts the draft quality, and the roadmap's twelve-week re-score is exactly where that trust gets tested honestly rather than assumed, there's a reasonable next step where low-risk, templated status updates go out with a lighter review, not none.
Similar-Claim Finder is the one I'd expect to compound in value fastest, because it gets better the more claims run through the redesigned workflow, not because anyone tunes it. That's genuinely different economics from the other two: the Summariser and the Drafter save time per claim starting on day one and roughly hold steady, while a precedent tool like this one is quietly building an asset the team didn't have before, a searchable memory of how they've actually handled a freight claim like this one, not a policy document nobody reads. Whether that asset gets managed deliberately, or just accumulates, is worth a specific decision, not an accident.
The three applications, their descriptions and the estimated time saved above are all invented for this sample. In the session, the applications built are whichever two to three are most useful for the tasks your own team actually brings in.
PRAXORALAB Sequenced Workforce Adoption Roadmap
The redesigned workflow, AI-literacy baseline and working applications above, brought together into one sequenced plan by all three facilitators, ordered by dependency rather than by department.
- Run the redesigned four-stage claims workflow in parallel with the old one for two weeks before retiring the handoffs no longer used.
- Re-run the prompt-literacy segment of the AI-literacy baseline for the two lowest-scoring team members, since Stage 1's fast-track routing depends on prompts good enough to trust without heavy rewriting.
- Move the Claims Intake Summariser inside the actual intake form, not a separate browser tab, closing the workflow-integration gap the baseline flagged.
- Extend the Claims Status Reply Drafter and Similar-Claim Finder to the full nine-person team, not only the three to five who built them.
- Set a monthly check-in for the two team members who said they'd likely stop using AI without follow-up, rather than assuming week-one enthusiasm holds.
- Track the fast-track threshold's actual claim volume for four weeks and adjust the $500 cut-off if the split looks wrong.
- Re-score the AI-literacy baseline against this same five-dimension scorecard and compare against week one.
- Decide whether a fourth application, most likely a settlement-calculation checker, is worth building next, based on where Stage 4 still runs slowest.
- Present the redesigned workflow, the re-scored baseline and the three applications together to Kestrel's ops leadership as one adoption roadmap, not three separate initiatives.
The three of us run our own segments of this day separately for a reason: workflow redesign, AI-literacy training and hands-on application-building are different skills, and compressing them into one generalist session tends to produce a shallower version of all three. But a day that stays separate all the way to 5pm produces three good half-days and no roadmap, which is why this closing session exists, and why the plan on this page is sequenced rather than three parallel workstreams running on their own clocks.
The order matters as much as the content. Weeks one to three exist because the redesigned workflow and the AI-literacy gaps are entangled with each other in a way that's easy to miss if you only look at one scorecard at a time: the Claims Intake Summariser can only do useful work inside a workflow that has a named triage lead to hand its flag to, and that same intake step only saves real time once the officers using it can write a prompt worth trusting without a rewrite. Sequencing the workflow change, the prompt-literacy refresh and the tool's move inside the actual intake form into the same three weeks isn't tidiness for its own sake, it's closing three gaps that would each individually stall the other two if left to their own timeline.
Weeks four to eight are where adoption either becomes real or becomes a memory of a good training day. Extending the two lighter-touch applications to the full team, rather than leaving them with the three to five people who happened to build them, is the step organisations skip most often under time pressure, because a pilot that stays a pilot still looks like progress on a status update. It's also exactly the phase we built the monthly check-in for the two team members who told us, honestly, that they expected to drop off: a roadmap that only plans for the workforce's most confident people isn't a workforce roadmap, it's a pilot report.
What we're looking for at week twelve is not a perfect re-scored baseline or a flawless workflow. It's a Kestrel Freight Solutions that can show its own ops leadership one connected plan, a redesigned workflow, a re-scored team and three working tools, and explain why each one needed the other two to actually land. That connective explanation, more than any individual score on these four pages, is what one sequenced roadmap gives an organisation that three separate initiatives never do.
Every score, quote and figure on these four pages is invented for Kestrel Freight Solutions, a fictional company, so the format of what a participant leaves with can be judged before enquiring. It is not a real client's deliverable, and no organisation named Kestrel Freight Solutions is a Praxora Lab client. The session itself works from your own team's own function, in the room, on the day.
One full day, three facilitators, sequenced into one roadmap.