Sales enablement and the customer portal at SCIEX

What we can see from the outside, what we would propose, and what we need to understand from the inside.

Prepared for Nando Ferran Sánchez, Drum'N'Code, October 2026

Part 1 is hypotheses

We read them from the outside, from public material, and may have them wrong. It ends with two questions whose answers matter more than anything we wrote.

Part 2 is the interface

Here we are not guessing. We went through your portal, collected specific places and redrew it. It holds even if you disagree with every hypothesis in Part 1.

A working document, not a commercial proposal. Nothing here is estimated or scoped. The concept is our assumption from public information, not an existing SCIEX system; names, documents and figures in it are fictional.

What we looked at, and where we think the gap is

We looked at sciex.com, SCIEX Now, the shop, the Learning Hub, the community, the Channel Partner Portal, the request-a-quote and request-information forms, the ROI calculators, your press releases and technical notes. For comparison: Thermo Fisher, Agilent and Waters.

You are already investing in this direction. SCIEX itself described the SCIEX Now spring 2026 release as a step toward making the portal the central place for the customer. We are not proposing that you start moving. We are proposing a look at one stretch that, as far as we can see from the outside, is not covered yet.

Between the quote request and the purchase of an instrument, the customer portal plays no part in the conversation.

What is directly visible

A customer still choosing sees zeros: zero instruments, cases, software. Nothing relates to a purchase.
Four ROI calculators, each inside a product page. One currency; the result is neither saved nor sent anywhere.
The only route to a price or a substantive technical answer is a form.
After the form is submitted, nothing in the portal changes.
No competitor has a portal at SCIEX Now level, and no one has a shared space for the purchase itself, including you.

What we infer, and where we may be wrong

The conversation moves to email, and finance, IT and procurement approve with no shared surface. Technical answers come from scarce experts, and some share of them is routine. Deals sit longer at certain steps than anyone would like, which is hard to see from outside.

How much is true, only you know. That is what the two questions in this deck are for.

Where this probably costs money

Assumptions read from the outside. Some of them are certainly already solved internally.

Configuration and quoting

Every sale is a bundle: instrument, front end, software, consumables, service plan. The knowledge to assemble a valid one sits with a few people, and a new salesperson needs months to acquire it.

Assembling the answer

One substantive reply pulls together specs, application notes, a method, regulatory documents, price and demo plan. The content is organised for a researcher, not for a seller.

Capture, qualification, routing

Request a quote is a generic form: a PhD student with a grant and a pharma company with an approved budget look identical. Matrix, analytes, LOQ, throughput, standard and market are not asked.

Account knowledge

SCIEX Now already holds what most manufacturers would pay for: instruments, software versions, end-of-support, cases, contracts, training, StatusScope. Does the seller see it in one place?

Platforms and integrations

Customer data is spread across CRM, ERP, SCIEX Now, the shop, training, the community and the Partner Portal. Any separate new login dies within a quarter.

Dashboards and measurability

It is not obvious where deals stall: quoting, demo, regulatory review or procurement. Without that, enablement is hard to defend with a budget, especially after a reorganisation.

The layer that pulls all of this together for the customer today is the salesperson’s own head.

A “My deal” section inside SCIEX Now

We do not rebuild the portal. We add one menu item that appears when the customer has an open instrument request, and disappears after the purchase.

Status and plan. Who does what, and by when.
Every document in its current version: the answer, the sample test report, the quote, the technical documentation for IT and Quality.
Every SCIEX calculator in one place. ROI, software savings, hidden costs. Saved to the deal and exported to PDF.
Access control. The customer adds finance, IT and procurement and sets what each can see.
Questions and answers in the deal, not in an inbox.

Two states of the portal, not one overloaded screen: while the deal is open there is a deal section; once the instrument is bought it moves into the familiar blocks. SCIEX side: an account manager and a technical specialist. The market calls this format a Digital Sales Room.

Concept: My deal section on the SCIEX Now dashboard

Enlarge

Concept screen: “My deal” in the portal. Customer names and data are fictional.

Inside the deal: five tabs

Tab	What it resolves
Status and plan	Customer and SCIEX see the same next step and the same date
Documents	One current version for every participant
Calculators	The calculation is saved to the deal and goes to finance as a PDF
Participants and access	Several people decide on the customer’s side, and each sees only their part
Questions	A question is asked once and stays in the deal’s history

In this concept we deliberately changed nothing visually and worked in your current styling, so the function would be visible rather than the design. Everything about design is in Part 2.

Enlarge

Concept screen: deal detail page. Names and figures are fictional.

A Content Assistant

For two audiences: your sales team, and your 160+ channel partners, who already have the Partner Portal as a natural home for it.

Searches publications, product descriptions, documentation and regulatory documents.
Produces what is needed: a reply to the customer, a set of materials, a tender response.
Asks first for matrix, analytes, required LOQ and market, rather than after the third email.
Translates material into the customer’s language.
Shows its sources, so the answer can be checked before it is sent.

The effect we aim at is not the speed of the answer but who spends time producing it. If a share of routine technical questions reaches application scientists, the assistant lets a seller or partner arrive with requirements already formulated. For partners this matters most: your scientist is not sitting next to them.

Where we draw the line on AI

Search across a corpus that is already properly structured.
Extracting structure from documents.
Drafting something a human signs off.

These are the three things it is good at. It is good at nothing that must be precise in a regulated context without a human in the loop. With IVD and research-use products we would restrict AI to assembling from approved sources and never generating claims.

Findability is a taxonomy problem first and an AI problem second.

From request to purchase, in one place

The customer sends a request and a deal section appears in their portal. The salesperson prepares the answer through the Content Assistant, a technical specialist approves it, and it lands in the same place.

From there the whole purchase runs inside that section, and the salesperson can see the customer’s activity.

Highlighted in the diagram is what we would build. The rest already exists at SCIEX.

What changes

Problem	Solution	What improves
The portal is empty for people still choosing	“My deal” section	The customer sees status and next step
Approvals scattered across email	Documents in the section	One current version for every participant
The calculator result goes nowhere	Calculators in the section, PDF export	Finance receives a finished calculation
Routine technical questions reach scarce expertise	Content Assistant	The assistant takes the routine, specialists take the hard cases
Partners sell without a scientist nearby	The same assistant in the Partner Portal	160+ partners answer at the same level
Customer activity is invisible	Signals from the section into Salesforce	You can see where a deal is sitting
No visibility into which material works	Analytics from the section and the assistant	You see what is read and what is missing

And separately, the data. Every customer action lands in Salesforce: opened the report, ran the ROI calculation, invited their finance colleague, did nothing for two weeks. Product marketing gets feedback on its material, and leadership gets a comparable picture of where deals stall.

Two questions that matter more than this entire document

Everything above was read from the outside. Some of it is certainly already solved, some we see incorrectly, and the thing that matters most may not be on the list at all. So we would rather not open by arguing for our own hypotheses.

1

What does SCIEX mean by sales enablement, and what situation pushed the topic to the surface?

You raised this direction yourself. We would rather hear how you frame it: what should get better, for whom, and whose request put it on the table. A tool for an application scientist preparing a demo and a tool for inside sales are two different products, and the choice is made here, not in a technical discussion.

2

Thinking about the last few instrument deals, where was it hardest?

Not where the data says it took longest, but where it felt worst for the people involved: what was done by hand, what was asked more than once, where everything waited on one person. What the sales team names first is usually where a tool pays for itself soonest.

Then we would need to understand

who carries the deal and where it changes hands
how a valid configuration is assembled today
what is validated before anything goes to a customer, and who signs off
what SCIEX knows about an account that the seller cannot see
what is already on the SCIEX Now roadmap

What you get afterwards, at no cost

a map of the current process, marked with where the hours go and where deals stall
a shortlist of three to five candidate tools, with an honest note on what is not worth building
a clickable prototype of the strongest one
a phased plan whose first step is small enough to survive a reorganisation

Four to six conversations of 45 minutesTwo to three weeksNothing confidential

Writing software has stopped being the expensive part. Deciding what to write has not.

That is not a slogan about AI. It is how our team works now, and it changes what a first step can look like. Instead of a proposal and a scoping phase, a short validation sprint that puts something in front of your people to react to.

Two to three weeksNo costNo access to your systemsNothing confidential

What we need from you

45 minutes, and roughly twenty real questions your sales team and your channel partners actually receive.

1. A working prototype

Of whichever idea survives the two questions. Not a mockup: something a salesperson can be sat in front of, click through, and tell you is wrong. The concept screens and the redesigned portal in this document were produced in days, on spare capacity, from public material alone.

2. A retrieval spike across your public corpus

The real risk in the assistant idea is not the model but whether your material is structured well enough to be retrieved against a customer’s situation. We index a defined subset of the Resource Hub, run real sales questions and show the answers with their sources. It tells you whether this works on your content, and what would have to change in the taxonomy first.

3. A one-page engineering note

What is worth building, what is worth integrating into what you already run, and what we would advise you not to build at all.

Where we draw the line. Prototype code supports a decision and does not ship. With IVD and research-use products we would not place a model between your claims and your customers without a person accountable. What goes to production is written and reviewed the ordinary way, with tests and an owner. What is in it for us. We find out whether there is a real project before either side commits. Bogdan called it a sporting interest, and that is accurate.

If it holds up, where a pilot would start

novus V55
EMEAI

One instrument, one region.

35%

smaller footprint than the 5500+

40%

lower energy consumption than the 5500+

It launched in June 2026, and deals on it are only now moving, so a pilot disrupts nothing established.
It sells on economics as much as sensitivity. That is precisely the argument a calculator should produce and send to the customer’s finance colleague as a PDF.
It came to market with SCIEX OS 5.0 and AI enablement tools, so an assistant for the sales team falls in the same line rather than looking like a separate initiative.
One region means one set of regulatory requirements and one set of sellers. A measurable result within a quarter.

Next step. 45 minutes with you, and with someone who actually runs an instrument deal.

The interface

What follows is where we are not guessing. We went through your portal, collected specific places and redrew it. This part does not depend on any hypothesis above.

What we see in the portal

SCIEX Now serves several roles at once and has accumulated over years. It is an objectively difficult system, and we looked at it as the entry point for a new user. Here is what is directly visible.

Actions are inconsistent

In the instruments block, Manage My Instruments, Add instruments and View all instruments have different widths and styles and are not aligned. Neighbouring blocks repeat it differently each time.

Elements overlap

“Sync Now” is not visually attached to the instrument it belongs to, so it is unclear what is being synchronised.

The marketing header dominates

The user has already logged in to their own space, yet navigation built for a site visitor takes more attention than their own data.

Leaving the account unnoticed

Community, Learning Hub and courses land on a different domain with different navigation and visual language. The user stops knowing whether they are still inside their account.

The first screen is zeros

Zero instruments, zero cases, zero software. The elements are there, the content is not, and nothing says what to do next.

Duplicated content

A substantial part of the portal duplicates what the user reaches from the site: resources, training, community.

None of this is a matter of taste. All of it is visible within ten minutes in the portal, which is why we decided to show it rather than describe it.

Enlarge

Concept screen: portal redesign. Same blocks, same content, same sections; only the presentation changed.

What it could look like

Portal separated from the marketing site. Its own left-hand navigation, search at the top, the user’s own data first.
Blocks show state, not zeros: instrument status, software activation, learning progress.
Unified actions. Exactly two per block, same style and width.
Real instrument images in the Market Place instead of grey placeholders.
Request a quote stays a persistent header action, the one point where Part 2 meets Part 1.
Guide me through dashboard is kept, but no longer competes with the content.

We added no functionality. Our designer did this on spare capacity, with no brief and no obligation on your side. The prototype is yours whether or not this conversation continues.

Open the clickable prototype

You already have an AI assistant, but it lives separately

We deliberately tested your site’s assistant before proposing anything. It is decent: it understands the context of the page you are on, and for a prompt such as “I have a blood test laboratory” it guides you further across the site.

It works within the page, not within the task

Finding what is needed for a specific situation across the whole corpus of material is not something it does.

It is not connected to the portal at all

Once a user enters SCIEX Now they effectively lose it, and from inside the portal it is not clear what it offers.

What could be done without building a second assistant

An assistant inside the portal that can see your instruments, software, courses and cases, and answers with that in view.
An answer saved into the portal rather than disappearing with the session.
Prompts drawn from the install base: a software version past support, a service contract expiring, an unfinished course.

Our designer can show a few options for how this looks inside the portal. That is a matter of days, on the same terms, ahead of any agreement.

We are not trying to sell you something you have not yet articulated. Code is just code, and these days a model handles most of it. Working out what would become an effective tool specifically for SCIEX is the part worth spending time on.

ZolaGroup, corporate services in the UAE

We have not built software for mass spectrometry. What we bring is a class of problem: a configured sale through a partner network, regulations that change what a valid configuration looks like, several decision-makers on the buying side, and a long tail after the order. ZolaGroup sells company formation, residency visas and bank accounts, and every sale is a configured bundle. We built the platform that carries it end to end.

An intake that qualifies. A conversational questionnaire that validates answers, skips what is known and clarifies ambiguity. Every answer is kept as structured data.
A configurator that produces valid bundles. The request profile is matched to a catalogue and business rules, and returns one to three valid options with a full cost breakdown, exported to PDF.
A human approval gate in front of the AI. Proposals wait in a queue until a person releases them, and the assistant works only over an approved content source.
A deal room for everything after the quote. Statuses, documents with review, an activity stream, in-case questions, batched notifications and role separation.
A channel layer. Introducers have referral links, see only their leads and carry a configurable percentage with an earnings history.

Where the analogy stops: a visa application is not an instrument. What transfers is the shape of the sale, and each component we propose is one we have already built.

ZolaGroup services form with an AI assistant panel

Enlarge

ZolaGroup: services form with an assistant that clarifies each question.

Octopus AI (Loadify), transport management in the US

A platform used by dispatchers, drivers and accounting teams, with 80,000+ registered users. It is the one case in our portfolio that touches several of the areas above at once.

Qualification at the point of entry

The demo request form asks for the current TMS, the MC number and fleet size in ranges. The enquiry reaches a salesperson already carrying its context, and it is immediately clear where to route it. The point is not collecting more fields but asking the three or four that determine both qualification and routing.

Extracting structure from documents

AI pulls the key fields out of Rate Confirmations and removes manual entry. The same mechanism runs in our Invoice Auditor, which reconciles supplier invoices against expected values so that a person handles the exceptions rather than the documents.

Integrating rather than replacing

Fuel cards, tolls, GPS/ELD and accounting systems are connected through a thin application layer over systems the client already ran. In an environment like yours we expect most of the answer to be integration rather than new construction.

Dashboards and analytics

Planner views, and revenue and performance reporting, inside the platform.