Your client portal

Audience: the client-side sponsor or stakeholder for an engagement — the person who commissions the work, approves it, and pays for it.

The portal is where you see everything happening on your engagement in one place, and where you approve, request and pay. It is separate from the application being built for your staff.

Signing in

Go to the portal address your provider gave you and enter your email at /login. You will be emailed a sign-in link — click it and you are in. There is no password to remember or lose.

The link is single-use and expires quickly. If it has expired, just request another.

You see one engagement: yours. Other engagements, and other clients, are not visible to you and never will be.

What is here

Where to find what your provider made for you

On Deliverables. Each deliverable is one piece of the work — its own name, a short description of what it means, and where it stands. When it is handed over, the thing itself is attached to it: a document to download, or a link to open.

⚠️ Documents is the other direction. That page is for files you send your provider — a signed agreement, a logo, a list of content. Anything made for you appears on the deliverable it belongs to, not there.

The things worth doing properly

Approving contracts and quotes

Approve in the portal rather than by email. The approval is recorded against the engagement, so there is never a question later about what was agreed or when.

Asking for something new — change requests

If you want something outside what was agreed, raise a change request. Your provider turns it into a change order with a price, you approve it, and it becomes part of the scope.

This is the mechanism that keeps additions visible and agreed rather than arriving as a surprise on an invoice. Use it early and freely — it is not a complaint process, it is how scope grows honestly.

Following it after you have approved the price

Approving the quote is not the end of the story, and the portal does not pretend it is. Each request carries a label that tracks where the work actually stands:

The label is worked out from the release the change actually went out in, not from a box someone remembered to tick. That is why it can move without anyone telling you.

The same is true of changes your provider proposed

Sometimes the change starts with them, not with you: a change order appears under Change Orders with what is changing and what it costs, for you to approve or send back.

Once you approve one, it now follows the same labels as your own requests — and it will ask you for the production sign-off in the same way. Where a step needs you, it says Approved from the day you signed it and never moved again, which told you nothing about whether the work had been built, let alone shipped. If you have older change orders sitting on Approved, that is what you are looking at.

Approving a change for production

When a change reaches Ready for you to review, the portal shows an Approve for production button on that request. Open the preview site, look at the change in place, and press it when you are happy for it to go to your real site.

Two things about that button worth knowing:

• It is yours, not your provider’s. Your provider can build the change and put it on preview; only you can say it goes live. The screen where they work has no equivalent control.
• It only appears when there is genuinely something to look at. If the change is not on the preview site yet, the button is not there, and the server refuses the action even if you reach for it another way. You are never asked to approve something you cannot see.

⚠️ Approving for production is not a promise about when. It goes out with the next release your provider makes.

If your engagement has no preview site

Some engagements do not have one. A preview site is a second, separate copy of your app that your provider runs alongside the real one, and not every engagement is set up with it.

When there is no preview site there is no review step: a change goes from In progress straight to Live when your provider ships it. You are not asked to approve it first, because there would be nothing to look at.

⚙️ The portal says so on the request itself, so you are never left waiting for a step that is not coming. If you would rather review changes before they reach your live app, ask your provider — it is a change to how your engagement is set up, not something you can switch on from here.

“Done” — a change that shipped without a release

Some requests are settled without any software changing: a report re-run, a setting adjusted, a question that turned out to be a misunderstanding. Those close as Done, with your provider’s note about what was actually done. It is a real ending, not a request that quietly stopped moving.

If it says “In progress” again after you approved it

Your approval does not expire, and you never need to give it twice.

Occasionally a change you approved will show as In progress for a while before it goes live. That means your provider is shipping it in a later release than the one you looked at — a common thing when several changes go out together. The portal says so on the request: “Your approval stands… Nothing is waiting on you.”

⚙️ It is not the same as the case below. This one is routine.

If something goes live and then stops being live

Releases can be rolled back — usually because something else in the same release misbehaved. When that happens to a release carrying your change, the request stops saying Live, and the portal tells you why in as many words: the change was live, the release it went out in has been rolled back, your approval still stands, and it will go back out.

You do not need to re-approve it, and nothing you did caused it.

Reading progress reports

Progress reports are generated from the real state of the engagement — the actual scope items and their status, the time recorded, what shipped. They are not a narrative written from memory. Read them; they are the cheapest way to notice a problem early.

Where the plan is

On the Overview, under the row of phases. The phases are the coarse arc of the engagement — Discovery, Scoping, Building, Handoff, Support — and beneath them runs the detailed plan: each dated milestone, with the finished ones faded back so your eye lands on what is next.

⚠️ Schedule is not that. It books a call.

Invoices

Invoices appear here when issued. Drafts are not visible to you — if you can see it, it has been issued. Where there is something to pay, you can pay from the portal.

An invoice for nothing — a zero total, which happens on unbilled or goodwill work — shows as “No payment due” and asks nothing of you. It is a record that the work was billed at zero, not a bill.

If a line is wrong, say so rather than paying it. Your provider records the dispute against the invoice so it is tracked to a resolution rather than living in an email thread.

Support

Raise problems through the portal. They arrive in your provider’s support queue with a visible status, rather than sitting in someone’s inbox.

Getting into the application itself

If an application has been delivered for your organisation, the portal will hand you straight into it — you do not need separate credentials. Your day-to-day staff sign in to that application directly; see Using your application.

A note on branding

The sign-in page is TTP-branded. Once you are signed in, you will see your provider’s branding. That is expected, not a misconfiguration.