What Is the Divide in Schlumberger Service Orders? A Field Checklist for Operators

If you're searching 'what is the divide' because you're about to sign off on a Schlumberger service order, the answer is simple: it's the gap between what the contract says the job includes and what actually shows up on location. This article is for the people who have to make that gap as small as possible—procurement leads, operations coordinators, wellsite supervisors. And no, this isn't about sparkling wine. If you were searching for 'Schlumberger brut,' you're not on that page.

I've been handling oilfield service orders for 9 years. I've personally made (and documented) 14 significant mistakes, totaling roughly $230,000 in wasted budget. The most frustrating part? Most of them were invisible until the job was already out of sequence. So here's how to avoid the same kind of week.

Before You Start: What This Checklist Assumes

Use this when you're working with a large integrated service provider—specifically Schlumberger (now SLB)—and you're responsible for making sure a service order is executed. If you're planning a single, simple service with no data deliverables, you probably don't need all five steps. If you're combining wireline, mud logging, drilling tools, and production testing under one order, you definitely do.

I'm not a Schlumberger insider, and I can't speak to their internal pricing. What I can tell you from an operations perspective is which gaps keep causing trouble.

Step 1: Write Down the Divide Before the Truck Leaves

'What is the divide?' In my world, it's the difference between the service description and the service boundary. Start with a one-page scope summary:

• What exactly is being performed (e.g., open-hole wireline logs, 12¼-in. section) and with which tool string?
• What is explicitly not included?
• Who approves last-minute changes at the location?
• What data or report is the final deliverable?

In my first year (2017), I made the classic mistake. I accepted 'standard wireline logging package' as if it meant we'd get everything we need. The truck arrived with a basic triple combo in the logging unit, but the well needed an additional sonic tool for the geomechanics request that had come in the week before. That was an extra mobilization: $21,000. The operation still ran—after a 10-hour wait.

The fix: define the tools and data names in writing and attach the exact well program. It feels redundant until it isn't.

Step 2: Check the Ticket, Not the Brand

Schlumberger is a huge ecosystem. 'SLB' on a ticket doesn't mean one crew. It can mean Schlumberger Wireline, Schlumberger Drilling Tools, M-I SWACO, Smith Bits, or a different product line depending on the region. They share the logo but not always the same dispatcher.

I once had a job where the operations manager approved 'Schlumberger' for a completion service. The ticket, read carefully, was not for the product line that owned the job. The wrong tool came. It took two days and two management chains to sort it out. The crew was great; the assignment was wrong.

So verify three things on the equipment dispatch note:

1. The product line name, not just the parent brand.
2. The physical tool names, not a service category.
3. The names of the crew lead and the on-call service coordinator.

If any of those is blank, call before the truck leaves. I don't have hard data on how often this causes shutdowns, but based on the jobs I've audited, my sense is it's around 10% of integrated orders.

Step 3: Define the Data Deliverable Before It's Recorded

This is the one most people overlook. With Schlumberger, the tool time is only half the job. The other half is a digital deliverable—logs, memory data, final reports, QA/QC summaries. If you don't specify the format, depth reference, and units, you'll get something, but it might not be compatible with your geoscience team.

I've had a $3,200 order where every single memory file had the wrong depth reference. It looked fine on the operator's screen. Back in the office, the data points were shifted by 2 ft. Straight to the trash. That error cost $890 to reprocess plus a 1-week delay.

So put your data requirements in the order: file format (LAS, DLIS, PDF), depth reference and units, QA/QC steps and who runs them, and delivery deadline. If a data answer sounds vague, ask for examples. What the field gives you is what the office is gonna use. (Yes, 'gonna'—data quality is that personal.)

Step 4: Don't Spread Your Acceptance Criteria Like Peanut Butter

The biggest source of friction I see: operators spread acceptance criteria across too many emails, phone calls, and invoice notes. It's thin, patchy, and impossible to inspect. Peanut butter is good for sandwiches, not for service order acceptance.

Instead, make one 'done list' in the order or statement of work. It should say what equipment and data are being delivered, what operational limits count as acceptable, what counts as a failure, and how re-runs are scheduled and paid.

I have mixed feelings about integrated contracts because they simplify procurement but blur accountability. With a single done list, though, there's nowhere for scope to hide.

Step 5: Hold a 'Miranda' Moment Before Signoff

Before you sign the service ticket, have a 10-minute verbal pass-down with the crew lead. I call it the Miranda moment: anything the crew doesn't say out loud now can be used against the rest of us later.

Ask the three questions:

1. 'What did we not get that was in the scope?'
2. 'What will be different about the data when we process it?'
3. 'What do you need from us before you can issue the final report?'

In September 2022, I had a wireline job where the wrong logging program got loaded in the truck. We caught it only after the tools were in the hole. $32,000 spent, zero usable data. If I had asked the crew lead the 'what will be different' question before they rigged down, we would have seen the issue. The program had a note that memory mode was enabled but the surface QA parameter was off—readable if someone was looking. I wasn't.

After the third rejection in Q1 2024, I made this checklist mandatory for every integrated job. We've caught 47 potential errors with it in 18 months. That's 47 mistakes that didn't become non-productive time.

When Not to Use This Checklist

I'm not a logistics expert, so I won't pretend this covers carrier optimization. And I don't know the legal side of Schlumberger's master service agreements; that's your contracts team's job. This checklist is for operational handoffs, not legal risk. At some point, you'll meet a service manager who says 'we can't do that in the field.' Believe them. It's better to replan than to argue against physics.

Common Mistakes I Still See

• Approving 'Schlumberger' as the whole vendor without checking the product line and exact toolstring.
• Writing 'data' as the deliverable and forgetting units.
• Spreading acceptance criteria over seven email threads (not thick enough).
• Skipping the verbal pass-down. The ticket can look complete and still be wrong.

The divide isn't a mystery. Most of the time it's a definition problem. Define the scope, the tool, the data, and what 'done' looks like. Then let Schlumberger do the thing they're actually good at. You're less likely to spend your budget on re-runs, and you'll sleep a lot better.