Use cases / When someone needs an answer
Bug or expected? Before the 3 PM call.
A customer cut seats, 15 of their users lost access this morning, and only an engineer seems able to say whether it is a bug before the afternoon call.
Jigward checks the billing schedule, the account and the code, and returns a verdict and a reply support can send before the call. The reply and any credit stay with the support lead.
The film
Chapters
Read the narration
0:00 Fifteen users locked out
Jordan's customer just lost access for most of their team. The call is this afternoon. Bug or expected? Usually, that pulls an engineer like Maya out of planning. I'm Jigward. Jordan's mention makes this my Task. An admin already connected me to billing, accounts and our code, read only. So Maya can stay in planning.
0:24 What billing and the account show
Okay, billing first. Their admin scheduled this cut back in October. It took effect at this morning's renewal, exactly as asked. Billing tracks seats, not people. So I ask our accounts service. They were suspended, not deleted. And nobody was marked to stay active.
0:45 Expected, but never warned
Now the rule. When seats drop, the newest members are suspended unless the admin marked them to stay. By design, and tested. So why the surprise? On a staging test account, I repeat their cut, without confirming. The screen never says who gets suspended. I'll propose a fix.
1:09 An answer support can send
Last time, this got two different answers. I'll remember the rule and what it rests on, so the next answer matches. Not a bug. Here's a reply Jordan can send: nothing was deleted, here's how to choose who stays, and we should have warned them.
1:30 What was checked, and who decides
Every call and file I read stays on the Task. I also name what I couldn't check, like what their admin saw in October. Jordan has his answer before the call. The reply and any credit are his decision. And Maya never left planning.
What changes
Today. Support cannot see the billing schedule, the account's members or the code, so the question goes to an engineer, who drops planned work to rebuild the context. The answer lands in a thread or a direct message nobody finds again, and two engineers can give two different answers. Billing dashboards show the plan and support tools show the ticket; neither says what the code was designed to do.
-
Before: An engineer pulled out of planning to answer "bug or expected?".
With Jigward: A verdict from the billing schedule, the account and the code, before the call, while engineering stays in planning.
-
Before: "Working as designed", and a customer who still feels blindsided.
With Jigward: Not a bug, with the real gap named. The review screen never says who will be suspended.
-
Before: Two engineers, two different answers to the same seat question.
With Jigward: The rule and what it rests on kept in memory, so the next seat question gets the same answer.
What Jigward does
@Jigward a customer cut seats and 15 of their users were deactivated this morning. They're furious. Bug or expected? Can you find out before the 3 PM call?
Connected beforehand
- #support-escalations is named for the Context that holds the billing repository.
- Stripe is a custom integration worked out from its public documentation. An admin applied only its reading operations.
- The company's own accounts service answers at a public address with a key. It is a custom integration worked out from documentation the team provided, with only its reading operations applied.
- The billing repository is connected through GitHub.
- A staging browser profile holds a test admin's login. Jigward types the values itself, and they never reach the model.
-
Reads the billing schedule
In Stripe, the customer's admin scheduled a cut from 25 to 10 seats in October. It took effect at this morning's renewal, exactly as asked.
-
Asks what happened to the people
Billing counts seats, not people. The accounts service shows 15 members suspended, none deleted, and nobody marked to stay active.
-
Reads the rule in the code
The seat-enforcement code and its tests say that when seats drop, the newest members are suspended unless an admin marked them to stay. Expected, by design.
-
Repeats the cut on staging
On a staging test account, it repeats the same cut and stops before confirming. The review screen never says who will be suspended. Jigward offers that gap to engineering as an initiative and changes nothing.
-
Remembers the rule
The last seat question got two different answers. Jigward writes the rule to memory with the files and the commit it rests on.
-
Answers in the thread
Not a bug, but the customer should have been warned. A draft reply the support lead can edit and send, what was checked and what was not, and links to the case, the Task and the initiative.
Jigward in this case
-
Slack
The question arrives as a mention, becomes a Task, and the verdict and the draft reply go back to its thread.
-
Custom API
Stripe gives the subscription schedule, and the accounts service gives what happened to each member. Jigward calls no operation that changes data.
-
GitHub
A repository search finds the seat-enforcement code, and Jigward reads it with its tests. It changes no code.
-
Browser
A staging browser profile signs in as a test admin. Jigward repeats the cut and stops before confirming. The recording and screenshots stay on the Task.
-
Initiatives
The missing warning becomes an initiative, an offer engineering can take up or decline. Nothing starts until a member gives it as a Task.
-
Memory
The seat rule is kept with what it rests on, so the next seat question in this Context starts from the same answer.
What comes back, and what stays with the team
What comes back
- #support-escalations in Slack The verdict, a draft reply for the customer, what was and was not checked, and links to the support case, the Task and the initiative.
- The Context's Home in Jigward An initiative for engineering, to warn an admin at downgrade which members will be suspended.
- Jigward's memory How seat cuts work today, read from the code, with the files and the commit it rests on.
What the team decides
- Whether to send the reply, as written or edited. Jigward never contacts the customer.
- Any goodwill credit, which the support lead settles with their own lead. Jigward calls no operation that changes data.
- Whether engineering takes on the downgrade warning.
What Jigward did not check
- What the customer's admin saw in production in October.
- Whether the company emailed the admin about the change.
- Whether any suspended member had unsaved work.
- Each member's data, one by one. That it is intact rests on the code and the account summary.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.