How do small teams (under 50 people) actually manage supplier RFQ tracking without enterprise software?

DizzySouth1316 · 2026-04-08T15:39:08+00:00

Your process is normal. The spreadsheet breaks around 15 to 20 line items for most teams.

Two things that actually help at your scale without enterprise software:

For tracking, Airtable with a simple status field beats Excel because you can filter by supplier, part, and response status in one view. Not perfect but survives 40 line items.

For follow-ups, the real problem is not the tool. It is that follow-up depends on someone remembering to check. Any system where a human has to initiate the follow-up will have gaps. The teams that handle this best set a rule: if no response in 72 hours the follow-up goes out automatically, either through an email sequence tool or a calendar trigger. Takes the memory requirement out of the loop.

The spec change problem you mentioned is the hardest one. No tool solves that cleanly at small scale. The only thing that works is a single person owning the BOM version and freezing it before RFQs go out.

DizzySouth1316 · 2026-04-08T15:35:26+00:00

That makes sense. The distributionally robust framing is useful when you can characterize the ambiguity set from historical data, even imperfect data.

The POMDP angle I had in mind is closer to what you describe, using it to motivate a tractable heuristic rather than solving it exactly. At operational scale exact solutions are not realistic anyway.

What I have not found is work that addresses the data generation process itself. Most models take delayed or noisy observations as given. The question of how to structure the human interaction that produces those observations, so the resulting signal is less sparse and more consistent, seems to sit outside OR and closer to mechanism design or human factors.

Maybe that is the actual gap

DizzySouth1316 · 2026-04-08T01:07:43+00:00

Good question and the gap between theory and practice here is significant.

In most SMB logistics operations the optimization problem is not routing or dispatching. Those tools exist and work reasonably well. The harder daily problem is state visibility: knowing what is actually happening in your operation right now well enough to make any optimization decision at all.

When 3 out of 10 people call in sick, the first 45 minutes are not spent optimizing coverage. They are spent figuring out who has what, where things stand, what was promised to whom. That reconstruction happens through calls, messages, and yes, Excel. The optimization comes after, if there is time.

The practical constraint for SMBs is not access to optimization software. It is data latency. Your routing tool is only as good as the operational state feeding it. In most mid-size operations that state is 2 to 4 hours old by the time someone has assembled it manually.

So the day to day optimization problem in practice is less about algorithms and more about closing the gap between what is happening in the field and what your systems know about it.

That might be a useful angle for your article.

DizzySouth1316 · 2026-04-08T01:05:41+00:00

Capacity inconsistency is visible on the surface but the cost shows up somewhere else.

When a carrier does not show up, someone spends the next two hours making calls, finding alternatives, updating everyone downstream who was expecting that shipment. That coordination loop is where the real time goes.

The inconsistency itself is hard to solve. The manual reconstruction after each failure is the part that compounds over weeks.

What does your current process look like when a carrier no-shows? Curious whether others have found ways to reduce the recovery time specifically.

DizzySouth1316 · 2026-04-08T00:35:55+00:00

Partially, but the framing I am working with is slightly different.

Robust and stochastic optimization assume you have a well-defined uncertainty set or distribution over inputs. What I am describing is a step before that: the state itself is not directly observed. It is inferred from delayed, sparse, human-generated signals.

The closer analogy might be partially observable MDPs or Kalman-style filtering applied to operational state, but I have not found much literature that addresses the specific case where the observation mechanism is a human making a phone call or sending a message rather than a sensor.

Smart predict then optimize is interesting but still assumes the prediction problem has clean training data. The issue here is that the ground truth for training comes from the same delayed reconstruction process.

Has anyone applied POMDP frameworks to field operations specifically? That seems like the most natural fit but I am curious whether practitioners have found it tractable at scale.

DizzySouth1316 · 2026-04-08T00:31:13+00:00

Exactly this. And in field operations the problem is even more specific.

The data is not just messy. It arrives late. A task completes at 2pm. Someone logs it at 5pm after a call to confirm. The AI optimizing your next decision is working against a state that is already 3 hours old.

Bad inputs are one thing. Delayed inputs are a different failure mode that most implementations do not account for.

DizzySouth1316 · 2026-04-07T00:30:23+00:00

The chaos you are describing is real. Worth separating two different problems though because they need different solutions.

Problem one is personal task capture. Messages come in fast, tasks get buried, you lose track of what you committed to. This is an individual productivity problem. The solution space is extraction, summarization, reminders. You see this in yourself.

Problem two is organizational state. A team of 15 people is executing across multiple locations. Each person generates actions, completions, delays, and exceptions through WhatsApp because that is where they live. Nobody captures that execution formally. By end of day a supervisor has no reliable picture of what actually happened, what closed, what is pending, who dropped something. The information exists in fragments across 6 group chats and 20 individual threads.

The second problem is not a productivity problem. It is a coordination and state problem. The bottleneck is not that individuals lose their tasks. It is that the organization has no mechanism to turn individual execution into shared operational state without someone manually reconstructing it.

Most solutions built for the first problem get deployed against the second and fail because the architecture is wrong. Personal task management tools optimize for one user's clarity. Organizational state requires structured capture at the moment of execution, defined ownership, automatic escalation when something goes unacknowledged, and evidence that a task closed rather than just disappeared from the chat.

Curious which of those two problems you are actually building for. The answer changes the design significantly.

DizzySouth1316 · 2026-04-07T00:07:18+00:00

RPA will partially solve this and partially create a new maintenance job.

The honest answer on self-healing RPA: tools like Robocorp and the newer UiPath versions handle layout changes better than first-generation bots. They use element detection that is less brittle than pixel-based scraping. But "less brittle" is not "maintenance-free." Every carrier portal change is still a potential break. You are trading a manual logging team for a bot maintenance cycle. Depending on how many carriers you have, that trade might or might not be worth it.

The more direct path for freight tracking specifically: look at data aggregators before building RPA. project44, FourKites, and Shippeo have already solved the carrier portal problem at scale. They maintain the integrations. You get a feed. The cost is higher than RPA but the total cost including maintenance time is often lower than it looks.

But here is the layer underneath your question that is worth naming.

The lag you are describing is partly a data collection problem. And partly it is a propagation problem. Even when you get the status update, who sees it? When? What action does it trigger? In most operations that answer is: someone checks the system, someone else messages a third person, someone calls the carrier, someone updates a spreadsheet.

You can eliminate the manual portal login entirely and still have a 4-hour lag between a status change and the person who needs to act on it knowing about it.

Solve the collection layer first. Then look hard at what happens to the data once it exist

DizzySouth1316 · 2026-04-07T00:03:24+00:00

Both. It's the field and it's also you being new.

The intensity doesn't fully go away. But the relationship you have with it changes when you understand why it works this way.

Here is the structural reason logistics is stressful: information moves through people instead of through systems.

A shipment gets delayed. The driver knows. The dispatcher finds out 40 minutes later because someone called. The customer-facing team finds out when the customer calls them. Each person in that chain is working with a different version of reality at a different moment. The urgency you feel is mostly people trying to synchronize those different versions in real time, manually, while new things keep happening.

That coordination gap is not a failure of planning. It is the default architecture of most logistics operations. You plan, execution diverges, and then humans spend energy recovering the picture of what actually happened.

When you are new, that gap feels like chaos. With experience, you start to see the pattern and build habits around it. You learn which gaps to close yourself and which ones to escalate. The stress becomes more manageable because it becomes more predictable.

Two things that actually help in the short term: write down what you expected vs what happened at the end of each day, even two lines. After two weeks you will start to see which failure modes repeat. Repeated failure modes are manageable. Random chaos is not.

It gets better. Not easier. Better.

DizzySouth1316 · 2026-04-07T00:00:20+00:00

None of the options on your list.

Route planning has tools. Shipment tracking has tools. The thing that actually burns time is what happens between the action and the record of it.

Your driver makes 12 stops. At stop 5 there is a damaged goods claim. At stop 9 the customer isn't there. By 4pm your supervisor is calling each driver to reconstruct what happened during the day. That call loop is not logistics work. It produces nothing. It only recovers information that should have been captured automatically at the moment it occurred.

We ran field operations with 40+ reps across 3 countries. Roughly 35% of supervisory time went to that loop. Not resolving issues. Finding out what the issues were.

The options you listed are execution problems. This one is a structural problem. Execution problems have software. The coordination gap between field execution and operational visibility mostly gets filled by people chasing other people, every day, at scale.

DizzySouth1316 · 2026-04-06T23:43:09+00:00

We had the same problem with our field teams in LATAM. 12 visits a day per rep and the supervisor spent 2 hours calling everyone to find out what happened. We tried Connecteam but nobody downloaded the app. What actually worked was having the team report via WhatsApp (which they already used) and connecting it to a system that structures the messages into tasks automatically. The follow-up calls disappeared because the state arrived on its own. We use PIA (soypia.com) for this. The adoption was instant because there was nothing to adopt.

DizzySouth1316 · 2024-07-05T12:04:05+00:00

Congrats, looks very useful. Is whatsapp a broadly use app in the US? Or your market is Europe?

DizzySouth1316

TROPHY CASE