When a merchant can't find the refund button, they don't explore the interface. They open a support ticket. That ticket costs time — for the merchant, for the partner success team, and indirectly for Tamara. Multiply it by a growing merchant base across MENA, and "navigation confusion" becomes a measurable drag on operations.
I joined Tamara as a Product Manager in January 2024, taking ownership of the Partners Portal — the merchant-facing operating platform used by Tamara's merchant network to manage orders, settlements, invoices, team access, and integrations. The portal worked. But it had grown organically as Tamara's merchant offering expanded, and that growth had left marks: navigation that required you to already know where to look, onboarding that assumed familiarity, and a backlog of merchant-requested features that had accumulated without a coordinated delivery strategy.
The Problem: A Portal That Required a Map#
Tamara's Partners Portal covered significant operational ground. Merchants used it to capture and refund orders, download settlement reports, manage team members and roles, configure webhooks and API tokens, and generate tax invoices. The feature surface was genuinely useful. The problem was navigation.
Merchants couldn't find things.
As the portal grew, the navigation did too — but it grew by addition, not by redesign. Features landed where they fit at the time, not where merchants would intuitively look for them.
Support teams became search engines.
"How do I download a settlement report?" "Where do I add a user?" "How do I issue a refund?" These questions filled the partner success queue — not because the portal couldn't do these things, but because merchants couldn't find where.
First-login drop-off was real.
New merchants arrived at the portal and encountered a full-featured platform with no guidance. BNPL terminology (captures, settlements, refund windows) isn't universal. Merchants who couldn't orient themselves quickly leaned on support rather than self-serving.
Merchant-requested features had no coordinated delivery.
There was a growing backlog of specific, well-understood requests from merchants — filtering improvements, bulk actions, reporting enhancements. Each was reasonable. None had been shipped at pace.
A support ticket is a product failure. Not always — some questions are genuinely complex. But when the ticket says "where do I find X", that's a navigation problem, and navigation problems are solvable.
The Vision: From Operations Tool to Self-Service Platform#
The framing for Partners Portal 2.0 was a shift in what the portal was designed to do. Version 1.x was an operations tool: it gave merchants the ability to perform tasks. Version 2.0 was designed around self-service: merchants should be able to discover functionality, learn the platform, and complete workflows without requiring partner success team involvement.
Discoverability
Any merchant should be able to find any object or workflow within seconds, regardless of where they enter the portal.
Guided Adoption
New merchants should understand the platform enough to be operationally independent after their first session.
Feature Completeness
The backlog of merchant-requested enhancements should ship coherently, not in isolation.
Decision 1: Global Search#
The Problem
Merchants working with Tamara operated across multiple modules: order management, settlements, invoices, user management, webhooks, reports. Each module had its own navigation, its own search (where it existed), and its own mental model. Finding a specific order or settlement meant knowing which section of the portal to go to first.
The Insight
The insight was straightforward: the portal had good data and the operational objects were well-defined. Orders have IDs and customer details. Settlements have dates and amounts. Invoices have numbers. Users have names and emails. What was missing was a unified entry point that searched across all of them.
The Solution
Global Search indexed the portal's core operational objects and made them searchable from a single bar, available from any screen. Merchants could search by order ID, merchant order ID, customer name, customer phone, settlement ID, tax invoice number, username, or report name — and land directly on the relevant record.
The immediate effect was visible in the partner success queue. Navigation questions dropped significantly. Merchants who previously opened tickets to locate a specific order or settlement could find it themselves. The search bar didn't add new capabilities — it made existing ones accessible.
Decision 2: The Product Tour — and Why We Chose GuideSail#
New merchants arrived at the portal and encountered a powerful platform with no orientation. Tamara's BNPL model has specific terminology: captures (what triggers merchant disbursement), settlement cycles, refund windows, order statuses. Merchants unfamiliar with BNPL operations had to learn both the product and the platform at the same time.
The Build vs. Buy Decision
The options I evaluated for the product tour covered most of the market: Pendo, Appcues, and Intercom Product Tours. All three could technically do what I needed. None of them were the right fit.
Pendo, Appcues, and Intercom Product Tours are digital adoption platforms built for enterprises managing multiple products, multiple user segments, and complex analytics pipelines. They're priced accordingly. The use case I had was specific and bounded: step-by-step guidance for new merchants on their first login to a B2B portal. Paying for enterprise-grade user analytics infrastructure to ship a six-step onboarding tour would have been the wrong call — both commercially and technically, since implementation complexity would have added engineering cost on top of licensing cost.
I found GuideSail (getguidesail.com) — a focused product tour tool that matched the scope of the problem. No engineering days required for setup. Fast to implement. Sufficient feature set: step-by-step modals and tooltips. Right-priced for a targeted use case. But there was one gap.
The Negotiation: Co-Shaping the Product
GuideSail didn't yet have the trigger logic I needed: showing the tour only on a merchant's first login and skipping it on subsequent sessions. Without this, the tour would fire every time, becoming friction instead of guidance. I reached out directly to Hassan Siddiqui, GuideSail's developer, and laid out the requirement clearly: this was the condition we needed before Tamara could commit.
Hassan built it. And then something better happened: because Tamara's requirements had shaped the product in a direction that was useful for other customers too, Hassan created a new pricing tier specifically for Tamara's scope — a commercial arrangement that worked for both sides. GuideSail got a paying enterprise customer and a product signal that improved the tool. Tamara got the feature it needed at a price matched to the actual use case.
Not every vendor relationship is a take-it-or-leave-it evaluation. When the gap is specific and the developer is reachable, the right move is to describe the problem and see if it's buildable. The GuideSail partnership ended up being more interesting than a procurement decision: it was a co-development conversation.
The right tool for a problem isn't always the market leader. When the problem is bounded and the gap is specific, you can sometimes shape the tool rather than accepting it as-is. Right-sizing the solution — commercially and technically — is a product decision.
Tour Design
The tour covered six steps, triggering on first merchant login. Each step corresponded to a core portal section: Orders (the primary operational view), Captures (how merchant disbursement is triggered), Settlements (understanding the payout cycle), User Management (inviting teammates and managing access), Reports (downloading exports and invoices), and a completion state that confirmed the merchant was ready to operate independently.
First-session orientation improved. New merchant support queries — the "I don't understand what a capture is" and "where do I find my settlement" tickets — declined. Merchants who completed the tour moved through their first operational tasks faster than those who arrived before the tour existed.
Beyond Product: 57% Off the Email Bill#
Not every PM win shows up in a roadmap. Some of the highest-impact work happens at the edges — where product, engineering, and commercial operations intersect, and no one else is looking.
I noticed that Tamara's merchant portal email costs through Mailchimp were running higher than they should. The pricing model we were on auto-renewed when we hit our send limit — so instead of paying upfront for our actual volume, we were getting bumped to the next tier at the worst possible moment (when usage peaked) and paying the top-of-tier price repeatedly. No one had flagged it because it wasn't obviously wrong — it was just how the account had been set up.
Email authentication and list hygiene.
The [email protected] sender had accumulated deliverability problems: SPF and DKIM configuration wasn't clean, and the list contained stale addresses that were generating bounces. Bounces trigger retries. Retries consume send quota. Fixing the email authentication and cleaning the list reduced retry volume significantly.
Pricing model restructure.
I switched from renewal-on-limit to an upfront plan sized to our actual forecasted volume — calculated from historical send data plus a growth buffer. Then set a calendar reminder to revisit the plan every three months, comparing actuals to forecast and adjusting before the next period.
The combined effect: 57% reduction in what Tamara paid for portal emails. The fix took a few hours of investigation and a pricing plan change. The ongoing cadence — a quarterly review of email volume against the current plan — was a five-minute calendar event that prevented the cost from drifting back up.
PMs who own a product own its economics too. If you're responsible for a feature that sends emails, you're responsible for what those emails cost. The pattern — understand the usage, match the pricing model to the reality, forecast, and review — applies to any vendor-billed service tied to usage.
Decision 3: Coordinated Merchant Feature Delivery#
Beyond search and onboarding, Partners Portal 2.0 included a structured push through the merchant-requested backlog. Over 15 features were shipped across the portal's operational surface — filtering improvements, workflow optimizations, reporting enhancements, and UI refinements that had been requested by merchants but hadn't made it through the prioritization cycle.
The PM work here was coordination, not invention. The requests were known. The engineering effort was understood. What was missing was a prioritized delivery plan that grouped related changes coherently rather than shipping them in isolation. Batching the delivery also meant merchants received a perceptibly improved portal rather than incremental changes that felt invisible.
A backlog of reasonable merchant requests doesn't need a big-bet product moment. It needs someone to own the prioritization and sequence the delivery.
Outcomes#
reduction in merchant support queries
Driven primarily by Global Search eliminating navigation friction and the product tour reducing first-session confusion. Partner success teams spent less time answering "where is X" questions.
improvement in merchant satisfaction scores
Measured through Tamara's merchant satisfaction tracking. The combination of faster task completion (search), better onboarding (tour), and resolved feature requests moved the needle across the merchant base.
merchant-requested features shipped
A coordinated push through the existing backlog. Individual features ranged from filtering improvements to workflow optimizations — none were large standalone bets, but collectively they represented meaningful coverage of merchant operational needs.
reduction in portal email costs
Self-initiated. Fixed email authentication and list hygiene to reduce retries, then restructured the Mailchimp pricing model from auto-renewal-on-limit to an upfront plan sized to forecasted volume, with a quarterly review cadence.