Contact Us
ClientA €3B global speciality chemicals company
SprintAn 8 to 10 week sprint, July 2025
Fieldwork30 employee interviews · 67 survey responses · 4 regions
Operational Improvement

Design the process for the people who use it twice a year

The situation

The process was built for buyers, and buyers were not the ones using it

An 8 to 10 week sprint, July 2025. A €3B global speciality chemicals company. One senior analyst and two analysts, 30 employee interviews, 67 survey responses, 4 regions. Capability: Operational Improvement.

Indirect tail spend is the long tail of small, low value purchases that never become a product: a software licence, a replacement sensor, a contractor for one job. Each is individually too small to question, and together they are a real number passing through a process nobody designs with care.

The client wanted to improve how it handled those purchases. It lacked clear roles, consistent supplier onboarding, meaning the steps a supplier completes before it can be ordered from and paid, and effective user support across regions.

The people raising these purchases are engineers, site supervisors and office managers, not buyers. They are the requestors: anyone who starts a purchase without purchasing being their job. They met fragmented tools and unclear instructions, and the result was delay, more support requests, and inefficiency in the process.

Without a standard approach, purchasing cycles slowed, indirect costs rose and system adoption stayed low. Adoption was lowest of all at manufacturing sites, where purchases were infrequent but complex. That last point is the problem in one line: the hardest purchases were being made by the people with the least practice.

Why it had not been solved

The evidence sat with the people who had least reason to gather it

A speciality chemicals company of this size employs procurement professionals who understand sourcing better than we do. Domain knowledge was not the gap, and we will not pretend it was.

The gap is who holds the evidence. Knowledge of where this process breaks does not sit with the procurement team, because the procurement team does not use the part that is broken. It sits with several hundred people across 4 regions who each touch it two or three times a year. Each holds one fragment, and a fragment on its own looks like one person having one bad week. From inside a single experience nobody can tell whether the process is wrong or the person was unlucky.

Then there is who could assemble it. The procurement team's attention goes to the contracts that carry the money, and the tail is by definition not where the money is. The requestors have no reason to learn a system they use twice a year, no time to map it, and no standing to redesign it. So the work sits in a gap: real, costed, and owned by nobody whose job it is.

That is the trade, and it is worth naming plainly. Not expertise the client lacked. Reach across 4 regions, and protected time to assemble what the reach collects, which nobody inside had spare.

How we approached it

Breadth first, because one complaint is deniable and 67 are not

The sprint set out to map tail spend processes and the role confusion in them, identify the system, process and support gaps holding back adoption, and recommend streamlined workflows and support. The lens was coverage rather than depth, and the survey did more work than usual. An interview tells you what one person met. 67 responses across 4 regions tell you whether that experience is the system or the individual, which a company cannot settle from inside while every complaint can be explained away one at a time.

  1. Map the process as requestors run it

    Region by region, as it is actually run, rather than as the policy describes it.

  2. Interview 30 employees across roles

    Including the infrequent users the process was failing, not only the people who use it daily.

  3. Survey 67 respondents across 4 regions

    To test whether the interview findings held at scale, or were four regions of anecdote.

  4. Separate the gaps by type

    System, process and support gaps have different owners, so they are sized and routed separately, for people who use the process rarely rather than daily.

What we delivered

Three kinds of gap, told apart, each with the fix it needs

  1. The current state map

    The process as it is run across 4 regions, including where roles are unclear and where requestors stop.

  2. The gap analysis

    System, process and support gaps separated, so each goes to the function that can act on it.

  3. Recommended workflows

    Streamlined steps, with responsibilities named rather than assumed.

  4. Support mechanisms

    Guidance and touchpoints built around infrequent users rather than trained buyers.

Telling the three apart is the point. Fixing a support problem by changing the system is expensive and does not work. Answering a system problem with more guidance pushes the work onto the requestor, which is how the process reached this state.

What changed for the client

Anecdote became evidence, and the evidence has an owner

Before the sprintAfter the handover
The process described in policy, not documented as runOne map of how it is run across 4 regions
Role confusion visible only as individual complaintsRole confusion evidenced across 67 responses, and named
System, process and support problems treated as one adoption problemThree gaps separated, each with an owner who can act
Guidance written for trained buyersRecommended support designed for people who buy twice a year

What that enables. The client can now make the case on tail spend from evidence rather than anecdote, and send each fix to the function that owns it. It can also tell a requestor who needs help from a process that needs changing, which it could not do before, because both reached the support desk looking identical.

What we recommended

Build for the twice a year user and the daily user is covered

  1. Redesign the requestor's path around the infrequent user

    A process that works for someone using it twice a year works for everyone. The reverse does not hold.

  2. Name the responsibility at each step

    Supplier onboarding included, rather than leaving it inferred.

  3. Put guidance where requestors stop

    Which the map identifies, rather than where a designer expects them to stop.

Scope of the result

Two figures size an opportunity, and the third is left out

Two figures are published here with the qualifier they carry. 30% reduction in support requests, potential identified. 2x faster vendor onboarding, potential identified. Both are modelled potential rather than time or money banked, and no baseline volumes are stated behind them, so they size an opportunity and do not report an outcome. An 8 to 10 week sprint ends at a recommendation, and what happens next belongs to the client.

A third figure is left out, and the reason is worth stating. A count of requestors re-engaged appears on the record. It carries no qualifier, no denominator and no date, and the line supporting it describes the re-engagement as already achieved. An engagement that ended at a handover cannot show that.

Source. Every figure in this article comes from the SprintlyWorks engagement record for Improving Indirect Tail Spend Management, a €3B global speciality chemicals company, July 2025, an 8 to 10 week sprint with 30 employee interviews and 67 survey responses across 4 regions. Clients are described and never named. Where a figure is identified or modelled rather than banked, this article says so.

The next step

Buy the first map, then run the method yourself

We put one senior analyst and two analysts on one defined question for 8 to 10 weeks. You get the fieldwork, the analysis and the handover, and you keep the method, so the second time you run it you do not need us.

If small purchases at your company generate support requests nobody has counted, that is the shape of problem this sprint is for. Write to rahul.abhisek@sprintlyworks.com and we will say in the first call whether it is worth the time. If a sprint is the wrong tool, we will say that instead.

Download the full study

More Case Studies

Have a similar requirement?

Contact us today to learn more about on-demand workforce and accelerate development on your most pivotal projects!

Quick Reads for Big Impact

Accelerating Success for Enterprises in 20+ Geographies

Launch Your Sprint with

Define your project, connect with top-tier consultants, and start making progress fast.

Augmented Team for Strategic Support

© 2026 All rights reserved. Business ID: 3096416-9
rahul.abhisek@sprintlyworks.com | Mannerheiminaukio 1a, 00100 Helsinki

Augmented Team of Business Analysts to Boost Capacity & Capability

Featured In

© 2025 All rights reserved

Augmented Team for Strategic Support

Featured inWorld Economic ForumKauppalehti Achievers 2024

Stay in the loop

Talk to us →