Use order events to identify exceptions, reconcile missing updates, and decide whether partner contact is necessary. Preserve uncertain outcomes before retrying a change.
Explore your workflow with SummerAn Empower Pharmacy follow-up workflow should detect an unanswered operational question, gather current evidence, and move the case to the right owner. It should also stop when the question is answered. Sending more messages is an activity metric; a verified customer answer is the outcome to measure.
Empower's public API material gives technical teams a useful starting point. The design below focuses on how a telehealth brand can use authorized evidence in support. The case examples are fictional.
Separate event ingestion from case decisions
Empower describes order-status webhooks that can notify a connected system of changes. An event can refresh a support view or prompt an investigation. It does not automatically justify a message to the pharmacy or customer.
Check the submission channel before flagging a missing event. Empower documents different event sequences for API submissions and orders sent through other channels: the latter do not receive the same initial receipt event. An absent notification may therefore be expected for that order, rather than a delivery failure. Use the sequence documented for your actual flow.
Preserve incoming events first, then decide whether an open case needs attention. Include prior contacts and promised response windows in that decision. A routine event may need only an internal refresh; a useful new answer may warrant one customer update.
Match the event to the right purchase
Customers can have more than one purchase, and a telehealth platform may use different references from its pharmacy partner. Establish the relationship through authoritative mappings created during your existing order flow.
Avoid matching on name alone or using the newest order as a default. If a mapping is missing, put the event into a visible reconciliation queue. An unresolved reference is an integration problem to investigate, not evidence that the customer's order does not exist.
Keep the original event available to authorized operators. A simplified case status helps people scan their queue, but someone should be able to inspect why it changed and which purchase it affects.
Use a case-driven follow-up rule
Scroll the table to compare all options →
| Situation | Follow-up decision |
|---|---|
| New event answers the open question | Update the case and consider closure |
| Earlier inquiry has a future response deadline | Wait while preserving ownership |
| Deadline passed and the question remains unanswered | Prepare one focused follow-up |
| Event appears older than current source evidence | Preserve history without replacing the newer finding |
| Event cannot be matched | Assign reference reconciliation |
| Customer asks a clinical question | Route that portion to the clinical team |
Use actual service expectations and case promises for timing. A generic daily schedule should not overwrite a pharmacy representative's specific response commitment or an operator's decision that the issue is resolved.
Work a missing-event example
A fictional customer's account page shows an old order state. They ask for an update. The support agent identifies the exact purchase and pharmacy reference, then obtains the current authorized pharmacy evidence.
The read reveals a newer operational state than the brand has stored. The agent now has two tasks: answer the customer's question using the verified finding, and report the stale integration state to its internal owner. Sending the pharmacy a request for information already available would add avoidable work.
If the current read also fails, the case stays open with a precise access blocker. Record what was attempted and who must repair access. The agent should not infer a pharmacy delay from a failed connection.
After access returns, recheck current evidence before resuming any prepared message. A message drafted during an outage may be obsolete once the underlying status is visible.
Follow shipment questions into the correct source
Empower's documentation distinguishes its order-status events from live carrier tracking. Its API introduction is the place to verify the current shipment-data limitations. Your support workflow should separately check carrier evidence when the customer's question depends on package movement.
Suppose an event includes a tracking reference but the carrier has no movement evidence. The agent should retain both findings and avoid declaring delivery progress that has not been established. If a follow-up is appropriate, ask about the specific missing fact rather than repeating a broad "status please" request.
This is an evidence-design issue. Even a technically perfect webhook integration can produce a poor customer answer if the application overstates what an event means.
Prevent duplicate work after timeouts
For outbound inquiries and authorized changes, record a concrete attempt and its result. A request may reach its destination even if your application does not receive a clean response. That uncertain outcome should pause automatic replay until someone or a supported read reconciles it.
Also link pharmacy contacts across help-desk tickets. A customer who emails after calling should not trigger a second inquiry about the same incident. The same principle applies when a new agent takes over the case or a job retries after a crash.
Expose a human override and retain the original history. Operators need to correct the operative next step without erasing the evidence that explains previous decisions.
Run a focused pilot
Start with internal order-status investigations for a small representative sample. Include a clean event, an event with missing references, repeated delivery, stale help-desk data, failed access, and an already resolved case.
Have a person compare each proposed answer with the original evidence. Track wrong purchase matches, duplicate inquiries, unsupported shipping claims, unresolved ownership, and review time. Review the cases that produced no outreach as well; silence can be correct when a question is already settled.
Expand only when the team understands the observed failures and can verify the repaired process on contrasting cases.
Review the workflow with Summer
Book a Summer demo with a fictional case timeline and the integration surfaces your Empower agreement makes available. Ask us to work through a missing-event scenario, identify the next owner, and explain how the case would close.
Agree which sources Summer can read and which communication your team will review. Bring the order submission channels as well as the pharmacy name; those details help scope the event and recovery work. The Empower MCP and API guide covers connection choices.
Common questions
Do webhooks eliminate follow-ups?
They can reduce stale information, but some customer questions still require investigation or a person at the responsible company. Use events to inform the case rather than equate an event with resolution.
Should every missing event create a pharmacy ticket?
First check current available evidence and the brand's own integration. The missing update may be a delivery or display problem in your application.
When should follow-ups stop?
Stop when the original operational need is settled, the incident is resolved by an authorized operator, or the relevant work ends. Preserve remaining unrelated issues as separate work.
Make your Empower Pharmacy support workflow easier.
Bring an example of the work slowing your team down. We’ll review your tools, the handoffs, and where Summer can help.
See Summer in actionWritten by Summer, the telehealth support product discussed in this guide. Sources were reviewed on October 17, 2026. Connection options can change; confirm current access with your vendor.