Design the process for the people who use it twice a year
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.
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.
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.
Map the process as requestors run it
Region by region, as it is actually run, rather than as the policy describes it.
Interview 30 employees across roles
Including the infrequent users the process was failing, not only the people who use it daily.
Survey 67 respondents across 4 regions
To test whether the interview findings held at scale, or were four regions of anecdote.
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.
Three kinds of gap, told apart, each with the fix it needs
The current state map
The process as it is run across 4 regions, including where roles are unclear and where requestors stop.
The gap analysis
System, process and support gaps separated, so each goes to the function that can act on it.
Recommended workflows
Streamlined steps, with responsibilities named rather than assumed.
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.
Anecdote became evidence, and the evidence has an owner
| Before the sprint | After the handover |
|---|---|
| The process described in policy, not documented as run | One map of how it is run across 4 regions |
| Role confusion visible only as individual complaints | Role confusion evidenced across 67 responses, and named |
| System, process and support problems treated as one adoption problem | Three gaps separated, each with an owner who can act |
| Guidance written for trained buyers | Recommended 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.
Build for the twice a year user and the daily user is covered
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.
Name the responsibility at each step
Supplier onboarding included, rather than leaving it inferred.
Put guidance where requestors stop
Which the map identifies, rather than where a designer expects them to stop.
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.
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.
Have a similar requirement?
Contact us today to learn more about on-demand workforce and accelerate development on your most pivotal projects!
Accelerating Success for Enterprises in 20+ Geographies

Launch Your Sprint with
Download the full report
Enter your email to access this exclusive case study.



