"The briefing stopped this morning."
A connected service changed how it signs in. Yesterday's briefing worked. Today it couldn't fetch its sources. The client has an 11 a.m. meeting and needs to know what happens next.
How will you get it running again, and what will you tell the client?
What to know
- Look before you change anything. Find what broke, what changed recently and who it affects. Keep a way back before you try a fix.
- Test updates before they go live. Read what changed, test the affected work, write down the result, and use the agreed time to roll it out.
- Check in with the client about use, failures, fixes and new needs. Suggest new work only when it solves a real problem, with its own scope and finish line.
Your assignment
Work through a practice problem: the client's briefing stopped after a connected service changed. Write down the impact, what you checked, a short-term workaround, the fix, proof it works, your update to the client, and how you'll prevent it next time.
Then draft a monthly check-in: work done, open issues, usage costs, and any new work you'd suggest, priced separately.
You're done when you can explain the problem and the recovery to a client, and tell included support from a new project.
Compare with one approach
Confirm the impact and read the logs. Follow the agreed support steps and give the client a plain status update, with a time for the next one. Offer a simple manual workaround if it helps. Restore the approved access, test a new briefing and check it's complete before things go back to normal. Record the fix and the prevention step in the monthly check-in.
Practice it in Field Academy: Boundary Keeper, Plan the recovery and measure the value. Messenger, Pass the opportunity to the builder.