Dá para apagar uma entrada do histórico?

Não. Os eventos são anotados quando ocorrem e não são reescritos. Uma mudança feita por engano e revertida figura como duas mudanças.

Registra também o que o atendimento automatizado fez?

Sim. Se ele criou o pedido, fica registrado igual a se uma pessoa tivesse criado. Além disso, as ações que ele toma ficam visíveis como notas dentro da conversa com o cliente.

E os pedidos que eu já tinha cadastrados?

Mostram a data de criação e nada anterior. O histórico começa quando a função passou a registrar; o anterior nunca foi guardado.

Histórico de alterações de um pedido: quem e quando

Q: Posso anotar na mão que liguei para o cliente?

Como evento da linha do tempo, não. O que dá para fazer é deixar como comentário no pedido: fica com o seu nome e a data, e quem ler depois vai ver no mesmo lugar.

A discussão que não dá para ganhar

O histórico de alterações de um pedido existe para encerrar uma discussão concreta: alguém mudou algo e ninguém assume.

Sem registro, essa conversa se resolve por memória. E a memória de três pessoas sobre uma terça de três semanas atrás nunca coincide.

O problema de fundo não é quem teve culpa. É que sem registro não dá para aprender nada: você não sabe se foi erro de uma pessoa, um passo mal explicado ou um processo que convida ao erro.

O que tem que ficar registrado

A lista curta do que deveria se registrar sozinho, sem ninguém escrever.

Evento	O que fica
Criação	Quem criou e quando, seja uma pessoa ou o atendimento automatizado
Mudança de status	De que status para qual, quem e quando
Edição	O que foi modificado
Exclusão	Quem e quando
Comentário	O texto, o autor e o momento

O importante dessa lista não é o que ela inclui. É que ela se escreve sozinha. Um registro que depende de alguém lembrar de preencher está vazio justo no dia em que você precisa.

O que se registra sozinho e o que não

Aqui vai o limite, porque uma promessa sem limite não dá para avaliar.

A linha do tempo cobre criação, mudanças de status, edições, exclusões e comentários. Não dá para adicionar uma entrada na mão: se você ligou para o cliente, isso não entra como evento do histórico.

O que dá para fazer é deixar como comentário no pedido. Fica com o seu nome e a data, no mesmo lugar, e cumpre a mesma função para quem ler depois.

O que não dá para recuperar

Um pedido criado antes de o registro existir mostra a data de criação e nada anterior. Essa história não foi guardada e não há como reconstruir.

Vale dizer porque é a primeira pergunta que aparece quando alguém começa a usar o histórico: "e o de antes?". O de antes não está.

Por que não se reescreve

Uma linha do tempo que pode ser editada não serve para o que existe.

Os eventos são anotados quando acontecem e ficam assim. Se alguém mudou o status por engano e depois voltou atrás, vão figurar as duas mudanças, não o resultado limpo. Isso é o correto: o erro faz parte do que aconteceu.

O que olhar quando algo deu errado

Uma ordem prática para usar, em vez de ler tudo de cima a baixo.

Comece pelo final. A última mudança antes de o problema aparecer costuma ser a que o causou.
Olhe quem. Se é sempre a mesma pessoa, é treinamento. Se são várias, é o processo.
Olhe quando. Erros concentrados num horário costumam falar de sobrecarga, não de descuido.
Leia os comentários daquele dia. Muitas vezes a explicação já está escrita ali.

O passo dois é o que muda a conversa com a sua equipe. Quando o registro mostra que quatro pessoas diferentes erraram, o problema deixa de ser de alguém.

Conclusões

Sem registro, a discussão se resolve por memória e ninguém aprende nada.
O que vale é que se anote sozinho, não que alguém lembre de preencher.
Cobre criação, status, edições, exclusões e comentários, e não aceita entradas na mão.
Pedidos anteriores ao registro não têm histórico recuperável.
Se o registro mostra que várias pessoas erraram, o problema é o processo.

Histórico de alterações de um pedido: quem mexeu e quando