Retail execution software usually assumes one brand and one hierarchy, but Philippine field teams increasingly sell multiple product lines under a single deployment. Mall-based and street-based teams follow different reporting chains, so a single dashboard for management only works when it mirrors the real org chart, not the brand split.
When one team ends up selling more than one thing
It’s common in Philippine retail deployment for a single field force to carry more than one brand or product category under the same account. A promoter working a mall kiosk might represent mobile phones this quarter and home appliances the next, reporting through supervisors who never touch either brand’s back-office systems. This isn’t a data entry problem. It’s an org chart problem that most software was never built to see.
It usually starts small. A trade marketing agency or manpower provider signs a second principal, or two accounts that used to run separately get folded under one client relationship for efficiency. Nobody redesigns the org chart on purpose. It just accumulates: a regional supervisor who used to manage one product line now has people from two reporting to them, a mall leader who used to be single-brand inherits a multi-brand booth, and the systems built for the original, simpler setup keep running as if nothing changed.
Retail execution and field automation tools are usually designed around a simple assumption: one company, one hierarchy, one dashboard. That assumption holds fine for a single-brand deployment. It breaks the moment a distributor, agency, or trade marketing provider takes on two product lines under one contract, because the org chart quietly splits into two shapes while the reporting tools stay flat. Management ends up staring at two dashboards that don’t talk to each other, trying to reconcile headcount, coverage, and attendance by hand, usually right before a client business review when someone finally asks for the combined number.
Mall-based and street-based are not the same deployment model
The split gets sharper once you look at how field teams are actually assigned. Some promoters and merchandisers are placed inside a fixed location, a mall or a modern trade store, where one supervisor owns that location and manages everyone posted there regardless of which brand they represent. Others work the streets: sari-sari stores, smaller shops, multi-brand electronics dealers, moving between several locations in a single day under a regional structure built around geography, not brand.
These two models don’t stress the same parts of a system. Mall-based deployment rewards a dashboard that can slice performance by location first and brand second, since the supervisor’s real job is running that store well regardless of product line. Street-based deployment rewards the opposite: a view built around routes, coverage per day, and territory, with brand as a filter applied afterward. A platform that only knows how to report “by brand” forces both teams to work around it instead of through it.
Add to that a further wrinkle: many companies have deliberately been consolidating trade supervisors from roving multi-mall coverage into single-mall ownership, to sharpen focus and cut travel time. Where a supervisor once covered eight scattered stores across a wide area, the direction now is one supervisor, one mall, full accountability for every promoter posted there. That’s a sound operational call. But it means the org chart itself changes shape mid-year, and whatever dashboard management relies on has to absorb that change without a rebuild, because the same supervisor role now needs to be measured differently than it was twelve months earlier.
The numbers behind mall and street deployment rarely land evenly across product lines either. One product category might dominate mall placements while a different one dominates street coverage, or the reverse, depending on where each brand’s retail partners actually sit. A dashboard that reports “total field force” as a single number flattens a distinction that matters enormously to how each team should be coached, staffed, and measured.
Reporting lines get more complicated before they get simpler
Layer the approval chain on top and the picture gets busier still. A promoter’s leave request typically needs sign-off from their direct supervisor, then a second approval further up the regional structure, before HR ever sees it. That two-level pattern is standard and reasonable on its own. It becomes a visibility problem only when the two levels sit on different systems, one tracking the mall-based hierarchy and another tracking the street-based one, with nothing showing management the combined picture.
This is where “nasa field pa” stops being a joke about slow replies and starts being an actual operational risk. If an overtime request has been sitting for three days because it’s waiting on an approver who reports through a different chain than the requester’s own dashboard assumes, nobody notices until payroll closes and someone asks why the numbers don’t match. Multiply that by a few hundred field staff and the gap between what happened and what management can see becomes exactly the kind of delay Tarkie’s own positioning names directly: field reports that take too long to compile turn insights into hindsights, and a fragmented approval chain is one of the quieter ways that delay gets built in.
There’s also a coaching cost that rarely shows up in any report. A regional supervisor who can only see their own product line’s attendance and coverage numbers has no way to notice that a mall leader managing a mixed team is consistently slower to approve requests for one brand’s promoters than another’s, a pattern that, left unaddressed, tends to show up later as attrition on whichever team feels like the afterthought.
Why “one dashboard per brand” doesn’t scale
The instinctive fix, building or buying a separate system for each product line and asking management to check both, works for exactly as long as there are two lines. It stops working the moment a third brand joins the account, or two previously separate teams get merged into a shared field force, which happens more often in Philippine trade marketing than most software vendors plan for. Each new dashboard adds another login, another export, another manual reconciliation at month-end.
The actual fix isn’t a bigger dashboard. It’s a dashboard built around the org chart the company actually has, not the org chart the software assumes. That means reporting structures, mall versus street deployment rules, and approval chains are configured once, correctly, and every brand or product line running through that structure inherits the same visibility automatically. Adding a second or third product line becomes a configuration change, not a second system to babysit.
This is a different design question than most field automation buyers ask up front. The typical evaluation checklist covers attendance, GPS check-ins, photo proof of visits, and sales or inventory capture, all necessary and all table stakes at this point. What it usually skips is a simple question: when this deployment adds a second brand or a merged team next year, does the reporting structure bend to fit, or does it require a second license, a second training rollout, and a second habit for supervisors to learn.
What org-chart-aware retail execution software actually shows
This is closer to how Tarkie approaches field deployments that outgrow a single, simple hierarchy. Megasoft runs attendance and coverage tracking for 1,500 merchandisers and coordinators through Tarkie, a scale where a flat, one-size dashboard would already be unworkable if it couldn’t reflect how that many people actually report and where they’re deployed. The platform is built to mirror a company’s real reporting lines, whether that’s a single supervisor owning one location or a regional structure managing roving teams across dozens of stores, so management sees one combined view instead of assembling it from separate exports.
That matters more as deployment models get less standard, not more. A company running mall-based and street-based teams under one account doesn’t need two products stitched together after the fact. It needs the underlying system to already understand that a mall leader and a regional supervisor are different roles with different spans of control, and that both roles can sit above people selling different things.
What to do this quarter
A few of these are worth doing before any software conversation, Tarkie or otherwise:
Map the actual reporting lines on a whiteboard, not from memory. Draw every tier from promoter to whoever signs off leave requests last, and mark which tiers are mall-based versus street-based. Most teams are surprised by how many tiers they actually have once it’s drawn out, and by how many of those tiers were never written down anywhere, just carried in a supervisor’s head.
Separate the mall and street deployment rules explicitly instead of assuming one policy covers both. Decide, in writing, how coverage, attendance, and approval routing differ between a fixed-location team and a roving one, and put that decision somewhere a new hire or a new supervisor can actually find it.
Time one leave or overtime request end to end. Count how many days it takes and how many separate systems, spreadsheets, or group chats it passes through before it’s approved. That number, more than any dashboard demo, is usually the clearest sign of where visibility is already breaking down.
Decide what “one dashboard” needs to show your management team specifically. Combined headcount and attendance across brands is a different requirement from combined sales performance, and conflating the two leads to a dashboard that tries to do everything and satisfies no one. Pick the two or three numbers management actually checks weekly and build outward from there.
Pilot a unified view with one region or one product line pairing before rolling it out company-wide. The org chart complications above tend to surface fastest in whichever region already runs mixed mall and street teams, which makes it the fastest place to learn what needs fixing before the rest of the company depends on it.
If your field teams already span more than one brand or product line, chances are your dashboards do too, and reconciling them by hand is where hours disappear every month. Tarkie builds field visibility around a company’s actual org chart, mall-based or street-based, single brand or several, so management works from one combined view instead of stitching exports together.
Frequently asked questions
What is retail execution software?
Retail execution software tracks how field teams, promoters, merchandisers, and trade supervisors carry out their in-store or in-route tasks, covering attendance, coverage, compliance, and reporting back to management in real time rather than through end-of-day paperwork.
How should a company manage a field team that sells more than one brand?
The reporting structure should be configured around how the team actually works, whether that is one supervisor owning a fixed location across brands or a regional structure managing roving multi-brand teams, so both patterns feed into a single management view instead of separate brand-specific systems.
What is the difference between mall-based and street-based field deployment?
Mall-based deployment assigns one supervisor to a fixed location who manages everyone posted there regardless of brand, while street-based deployment moves promoters and merchandisers across multiple stores or territories in a single day under a regional structure built around geography.
Can one dashboard show data for multiple brands or product lines?
Yes, provided the underlying system is configured around the company’s real org chart and approval chains rather than a single brand’s hierarchy, so that adding another product line becomes a configuration change instead of a second dashboard to maintain.
How many approval levels should a leave or overtime request pass through?
Most Philippine field deployments use a two-level approval pattern, the immediate supervisor followed by a regional or lead supervisor, and the number of levels matters less than whether both levels sit on the same system so requests do not stall between them unnoticed.