How to Think Before Calling a Vendor

A practical troubleshooting mindset for biomeds before escalating to manufacturer support

Vendor technical support can be one of the most useful tools a biomed has.

Published August 10, 2026 · Revised September 6, 2026

Back to Biomed Basics

What This Page Explains

This page covers how to prepare before calling manufacturer technical support, including:

The goal is not to avoid vendor support.

The goal is to use it well.

The Simple Version

Before calling, define what the device should do, what it actually does, and what evidence you already collected. Have the exact model, serial number, software version, error wording, operating conditions, accessories, recent changes, logs, measurements, and service history available. You do not need the diagnosis; you need a reproducible and well-bounded symptom.

Also know what help you are requesting: interpretation of a code, a test procedure, part identification, compatibility guidance, or escalation. A focused handoff lets support skip basic discovery and reduces the chance of changing configuration or ordering parts before the failure is understood.

Worked Example: Preparing a Useful Support Call

Instead of “the ventilator fails calibration,” report the exact calibration step, displayed code, test equipment and setup, measured value, expected limit, whether self-test passes, and what changed recently. Explain which consumables and known-good substitutions were tried and whether the failure follows a module.

Write down case number, representative, instructions, files exchanged, and any configuration changes. Confirm service authorization and backup requirements before updates or resets. After following support guidance, independently verify the repair and document the actual final results.

Start With the Complaint

The first step is understanding why the device came to you.

Do not immediately translate the complaint into your own diagnosis.

If the nurse says:

The monitor keeps losing SpO2.

Do not write:

Bad SpO2 board.

You do not know that yet.

The symptom is:

SpO2 intermittently drops out.

Possible causes could include:

A symptom describes what happened.

A diagnosis explains why it happened.

Keep those separate until you have evidence.

Get the Exact Model and Configuration

This sounds obvious, but it matters.

Manufacturers often have multiple models that look almost identical.

There may also be:

Before calling, collect:

Technical support may ask for this immediately.

Having it ready saves time and may change the entire troubleshooting path.

Understand the Failure

Try to describe exactly what is happening.

Instead of:

It doesn't work.

Try:

Unit powers normally, completes startup, and enters the main screen. When NIBP is started, the pump runs for approximately three seconds and stops with an inflation error before the cuff pressurizes.

That tells the vendor much more.

Another example:

Weak:

The ventilator has an alarm.

Better:

During the pre-use check, the unit consistently fails the expiratory valve test. The expiratory cassette has been removed, inspected, reseated, and tested with a second known-good cassette with the same result.

Now technical support knows you have already isolated part of the system.

Specific symptoms make better troubleshooting possible.

Try to Reproduce the Problem

If possible, see the failure yourself.

This is especially important with intermittent complaints.

Ask:

Try to recreate the conditions.

A monitor that supposedly shuts off during transport should probably be tested on battery and moved around.

A device that loses communication only when docked should be tested while docked.

A ventilator that fails during a specific self-test should be run through that same test.

The closer your bench conditions are to the original failure, the more meaningful your results become.

Check the Simple Things First

A surprising number of vendor calls eventually come back to something simple.

Before escalating, inspect the basics.

Depending on the equipment, that may include:

Do not skip these because the device is complicated.

Sophisticated medical equipment still fails because of simple things.

A $40,000 monitor can still have a bad cable.

Use a Known-Good Accessory When Possible

Swapping known-good accessories is one of the most powerful troubleshooting techniques available.

If a device fails with one sensor, cable, battery, module, cassette, or power supply, test with another compatible known-good one when appropriate.

This can quickly tell you whether the problem follows the accessory or stays with the device.

For example:

SpO2 fails with Sensor A.

Sensor A also fails on Monitor B.

Known-good Sensor B works correctly on Monitor A.

You now have much stronger evidence that the problem is the sensor.

Compare that with:

SpO2 doesn't work. I think the board is bad.

One is troubleshooting.

The other is guessing.

Power Cycle, But Do Not Stop There

Turning something off and back on can legitimately resolve certain software conditions.

That does not automatically mean the problem is fixed.

If a device locks up and a reboot restores operation, ask:

A reboot is a troubleshooting step.

It is not always a diagnosis.

Read the Error Message Carefully

Error messages often contain useful information.

Record the exact wording.

Do not rely on memory if you can avoid it.

There is a big difference between:

Gas error.

and:

Air supply pressure low.

Likewise:

Battery problem.

may actually have been:

Battery not recognized.

Those failures can have completely different causes.

Capture:

A picture of the screen can be useful if permitted by your facility and no patient information is present.

Do Not Assume the Error Code Identifies the Failed Part

An error code usually tells you what the device detected.

That is not always the same thing as telling you which component failed.

For example:

A flow error could result from:

The device knows the flow is wrong.

It may not know why.

Treat error codes as clues.

Do not treat them as automatic part numbers.

Review Service History

Before calling the vendor, check whether the device has been repaired for the same problem before.

Look at:

A single strange failure may be random.

The same failure happening three times over six months may tell a very different story.

Service history can also prevent you from repeating work that has already been tried.

If the same board has already been replaced twice, replacing it a third time without understanding the underlying problem may not be the best move.

Look for Patterns

Patterns are extremely useful when talking to vendor support.

Examples:

All five devices started showing this error after the latest software update.

This problem only happens when the unit is on battery.

The failure occurs after approximately 20 minutes of operation.

Every affected device is connected to the same docking station model.

The issue follows the module when moved to another chassis.

Those observations narrow the troubleshooting scope dramatically.

A vendor technician can do far more with a pattern than with:

We have a few units acting weird.

Check the Service Manual

If you have access to the manufacturer service manual, use it.

Look for:

You may find the answer without making the call.

Or you may learn enough to make the call much more productive.

For example, the manual may tell you:

If Test A passes and Test B fails, inspect Valve C before replacing the control board.

Now you have a logical troubleshooting path.

Know What You Have Already Proven

This is one of the most useful habits in troubleshooting.

Separate what you know from what you suspect.

You may know:

You may suspect:

Those are not the same thing.

When you call technical support, present the proven information first.

Then explain your suspicion.

For example:

I suspect the control board, but before ordering it I wanted to confirm whether there are any additional tests you recommend.

That is much more useful than:

I think the board is bad. Should I order one?

Have Your Test Equipment Ready

If the vendor is likely to walk you through testing, prepare before calling.

Depending on the device, you may need:

You do not want to spend half the support call searching for the equipment needed for the next step.

Know the Device's Current Condition

Before calling, know whether the equipment is:

Technical support may give you instructions that depend on the device's state.

What to Tell the Vendor

A useful opening might sound like this:

I'm working on a Servo-c, serial number XXXXX. It consistently fails the pre-use check during the expiratory cassette test. I tested it with two known-good expiratory cassettes, inspected and cleaned the seating area, and the failure remains with the ventilator. No visible damage is present. Software version is X.X. I wanted to see what the next recommended diagnostic step is before replacing parts.

That conversation can immediately move forward.

Compare it with:

Servo-c keeps failing. Any idea what it could be?

The vendor has to start from zero.

Ask Specific Questions

Good questions produce better answers.

Instead of:

What do you think is wrong?

Try:

You are not asking the vendor to guess.

You are asking them to help narrow the problem.

Do Not Let the Vendor Replace Your Judgment

Vendor support is valuable.

That does not mean every recommendation should be followed without thinking.

If technical support says:

Replace the main board.

Ask why.

You can politely ask:

Is there a test that confirms the board is the cause?

Or:

Could anything else produce the same symptom?

Sometimes the answer will be:

No, based on that error code and the tests you already performed, the board is the next step.

Great.

Now you understand the reasoning.

Other times you may discover that the recommendation is simply the most common next part.

That distinction matters when the board costs several thousand dollars.

Parts Cannons Are Expensive

A "parts cannon" approach means replacing parts until the problem goes away.

Sometimes this works.

It is rarely the best troubleshooting strategy.

Imagine this path:

Replace battery.

Problem remains.

Replace power supply.

Problem remains.

Replace interface board.

Problem remains.

Replace main board.

Problem disappears.

You technically fixed it.

But you spent a lot of money learning almost nothing.

A better troubleshooting process tries to isolate the failure before ordering expensive parts.

Sometimes you cannot isolate it completely.

That is reality.

But there should usually be some logic connecting the symptom to the part you are replacing.

Ask Whether Replacement Requires Additional Work

This can save you from an unpleasant surprise.

Before ordering a part, ask whether replacement requires:

You do not want to install a $4,000 board and then discover the device cannot function until a field service engineer programs it.

Know the complete repair path before ordering.

Be Careful With Intermittent Failures

Intermittent problems require very clear communication.

Tell the vendor:

Do not say:

It randomly shuts off sometimes.

Say:

Clinical staff reported two shutdowns during transport. I have reproduced one shutdown after approximately 45 minutes on battery. The unit does not shut down while connected to AC. Battery indicated 72% immediately before the failure.

Now you have something the vendor can troubleshoot.

Take Notes During the Call

Do not rely on memory.

Record:

If the repair becomes complicated later, these notes can be extremely useful.

They also improve your CMMS documentation.

Vendor Recommendation Is Not the Same as Work Performed

Your work order should distinguish between what technical support recommended and what you actually did.

For example:

Contacted manufacturer technical support, case #12345. Based on error code and diagnostic test results, support recommended replacement of the power supply assembly.

Then later:

Replaced power supply assembly per manufacturer recommendation. Completed functional verification and electrical safety testing. Unit passed all required checks and was returned to service.

That tells the full story.

Do not write:

Vendor fixed unit.

if the vendor never touched it.

When to Call the Vendor Early

There are times when spending hours troubleshooting first does not make sense.

Call early when:

Good troubleshooting does not mean opening every device yourself.

Knowing your repair limits is part of being a good technician.

Warranty Changes the Calculation

If the device is under warranty, be careful.

Opening the equipment or replacing parts yourself may affect warranty coverage depending on the manufacturer and agreement.

You may be able to diagnose the problem without performing the repair.

For example:

Device fails on both AC and known-good battery, no output from internal supply, under manufacturer warranty.

At that point, calling the vendor may be the smartest move.

Do not create a $5,000 warranty problem trying to save a 30-minute phone call.

Know When the Problem Is Not the Vendor's Problem

Sometimes the medical device is doing exactly what it should.

The issue may belong somewhere else.

Examples:

Network

The monitor has a valid IP address and communicates correctly on the network, but the destination server is unavailable.

That may require IT or the integration team.

Power

Multiple devices lose power from the same outlet.

That may require facilities.

Medical Gas

A ventilator reports low O2 supply and the wall outlet pressure is low.

The ventilator may be fine.

Accessories

The device works correctly with known-good accessories.

The problem may simply be the cable, sensor, or module.

Workflow

The equipment functions correctly, but staff expectations do not match how the system is configured.

That may require education or workflow review rather than repair.

Knowing when the equipment is not actually broken can save everyone time.

Do Not Call Three Departments With Three Different Stories

When problems cross Biomed, IT, Facilities, Clinical Engineering, Nursing, and vendors, communication can get messy.

Try to keep the technical facts consistent.

For example:

Monitor is functioning locally. Device has network connectivity and responds to ping. Data is not reaching the integration server. Escalating interface path to integration support.

That is much better than:

Biomed tells nursing the network is broken.

Nursing tells IT the monitor is broken.

IT tells the vendor the server is broken.

The vendor tells everyone the device is offline.

Clear facts prevent unnecessary finger-pointing.

Troubleshooting Is Building Evidence

The goal of troubleshooting is not to prove that your first guess was right.

The goal is to reduce uncertainty.

Every useful test should answer a question.

Swap the cable.

Did the problem follow the cable?

Use another battery.

Did the problem disappear?

Measure the voltage.

Is power reaching the board?

Run the self-test.

Which subsystem fails?

Review the logs.

What happened immediately before the error?

Each result narrows the possibilities.

That is troubleshooting.

A Useful Mental Checklist

Before calling the vendor, ask yourself:

What happened?

Can I clearly describe the symptom?

Can I reproduce it?

If not, what conditions were present when it happened?

What have I ruled out?

Power? Battery? Cables? Accessories? Setup?

What does the device say?

Error codes? Logs? Self-tests?

What changed recently?

Software? Parts? Accessories? Location? Network?

Has this happened before?

What does the service history show?

What am I asking the vendor?

Do I need a diagnostic step, documentation, clarification, part recommendation, software, or field service?

If you can answer those questions, you are probably ready for a productive support call.

Common Mistakes

Calling Before Looking at the Device

If the first thing technical support asks is:

What error code are you getting?

and your answer is:

I don't know, I haven't turned it on yet.

You probably called too early.

Diagnosing From the Work Order

The work order says:

Battery bad.

That does not mean the battery is bad.

That may simply be the user's interpretation of the symptom.

Verify it.

Giving the Vendor Your Conclusion Instead of the Symptom

Saying:

Main board is bad.

can steer the entire conversation in the wrong direction.

Start with the evidence.

Hiding What You Already Tried

Tell support what you did.

Otherwise they may spend twenty minutes asking you to repeat the same steps.

Replacing Parts Without Understanding Why

A vendor suggesting a part is useful.

Understanding why they suggested it is better.

Ignoring a Failed Repair

You replaced the recommended part and the problem remains.

That is valuable information.

Do not quietly move on and pretend the first diagnosis never happened.

Tell support.

The failed repair narrows the problem.

Failing to Record the Case Number

Three weeks later, another technician may need to continue the repair.

A vendor case number can save them from starting the entire conversation again.

Real-World Examples

Example 1: Patient Monitor Will Not Power On

Poor approach:

Monitor is dead. Call GE.

Better approach:

Verify outlet.

Verify power cord.

Inspect power inlet.

Try known-good battery.

Check whether charging indicator appears.

Determine whether the failure occurs on AC, battery, or both.

Then call if needed:

Monitor will not power on from AC or known-good charged battery. Power cord and outlet verified. No charge indicator or startup response. Looking for the next recommended internal power-supply diagnostic.

Now the vendor can move past the basics.

Example 2: Infusion Pump Gives Occlusion Alarms

The pump repeatedly gives downstream occlusion alarms.

Before assuming the pressure sensor is bad:

If the pump triggers early at a repeatable pressure outside specification, now you have evidence.

Example 3: Ventilator Fails Pre-Use Check

Do not call and say:

Pre-use check fails.

Find out where.

If it consistently fails the flow sensor calibration, say that.

If you swapped the flow sensor and the failure remains with the ventilator, say that too.

You have already eliminated one major possibility.

Example 4: ECG Machine Will Not Send to MUSE

Before calling the ECG manufacturer:

Does it acquire ECGs correctly?

Can it print?

Does it have a valid network connection?

Can it reach the network?

Is the MUSE destination configured correctly?

Are other ECG machines transmitting?

If every ECG machine suddenly stopped transmitting at the same time, replacing network cards in all of them is probably not the best starting point.

Look for the pattern.

Example 5: Defibrillator Fails Shock Test

A defibrillator does not deliver the expected energy during analyzer testing.

This is not the time for endless experimentation.

Verify your analyzer setup and test procedure.

Repeat the test.

Confirm the failure.

Review error logs.

Then escalate according to manufacturer procedure.

High-risk therapy equipment deserves disciplined troubleshooting and clear verification.

What Makes a Good Vendor Call

A good technical support call sounds something like:

I have a device with a repeatable failure.

Here is the exact model and software version.

Here is the error.

Here is when it occurs.

Here are the things I have already ruled out.

Here are the tests I performed.

Here is what I think may be happening.

What would you recommend checking next?

That is a technical conversation.

You and the vendor are working from the same evidence.

Final Thoughts for Biomeds

Calling vendor technical support is not admitting defeat.

It is another troubleshooting tool.

The difference is whether you use that tool intentionally.

You do not need to know the answer before calling.

If you already knew the answer, you probably would not need to call.

But you should know the problem.

Understand the complaint.

Reproduce it when possible.

Check the simple things.

Use known-good accessories.

Read the error message.

Review the history.

Gather evidence.

Then call with a specific question.

The goal is not to impress technical support with how much you already know.

The goal is to make the troubleshooting process efficient enough that you both get to the correct answer.

A biomed who can clearly say:

This is what happened, this is what I tested, this is what I ruled out, and this is what I need help understanding

is much easier to help than someone who simply says:

It's broken.

And over time, something else happens.

The more prepared you are before vendor calls, the more you learn from them.

Eventually, problems that once required a support call become problems you recognize immediately.

That is how troubleshooting experience grows.

— Jake

Important Note

This page is an educational overview for biomedical equipment technicians, clinical engineers, and healthcare technology staff. Always follow manufacturer service documentation, facility policies, applicable safety requirements, warranty restrictions, and the service scope established by your organization. High-risk repairs, proprietary procedures, and equipment outside your training or authorization should be escalated appropriately.

Related Biomed Basics

Back to Biomed Basics